I sometimes feel like I'm stepping out-of-line when pointing out some of the things you mentioned here to seasoned module developers, so I rarely do it. After all, they've been developing longer than I. They've been involved with Drupal longer than I. They should know better than I what is correct and acceptable and what is not. Am I being the "snot-nosed, know-it-all kid" (in experience, not age) when I point out the Drupal coding guidelines, or the discussions on the development mail list where these decisions are made? Don't these people already know all this stuff and where to find them if they need a refresher? I know I frequently need reminding, and constantly return to the source to verify or disprove what I think is correct.
Might I also add that following the guidelines not only helps with quality, but it also helps with readability for those times when "patch?" is uttered? If I feel like I am going to have to spend a lot more time with reading through the code in order to make a change or three (because of the lack of coding style or following the guidelines), I am less likely to go through the effort, especially if I feel like my effort won't be accepted or maintained.
I have heard it said that working in contrib is a way to be involved with Drupal without having to comply with the coding guidelines. For me, however, it's the starting point of what my code should look like and strive to achieve.
Cloverfield (2008; Holy crap, this was good. Would be a great double-header with The Host.); Communion (1989; Didn't work for me. Walken an odd choice, and it was more humorous than tense.); The 400 Blows (Criterion Spine #4) (1959; Truffaut's first feature; I'm looking forward to the Antoine Doinel followups.); Silent Rage (1982; Great beginning and Norris-appreciation, but slow and meandering ending.); Dakota Bound (2001; An actual plot, good cheesy action scenes, and lesbians. Amazingly good.);
D&D 4E: Treasure of Talon Pass (4E: we're just a combat engine! Buy miniatures.); D&D 4E: Monster Manual (A little too light on fluff for me. Prefer fluff.); Apple Volume 1 (As an art book, great. But for story? Bleh.); The Art of Dragon Magazine (I remember many of these from the original issues.); Mateki: The Magic Flute (I like Amano, but this felt like wasted sketches.);
Bravo!
I sometimes feel like I'm stepping out-of-line when pointing out some of the things you mentioned here to seasoned module developers, so I rarely do it. After all, they've been developing longer than I. They've been involved with Drupal longer than I. They should know better than I what is correct and acceptable and what is not. Am I being the "snot-nosed, know-it-all kid" (in experience, not age) when I point out the Drupal coding guidelines, or the discussions on the development mail list where these decisions are made? Don't these people already know all this stuff and where to find them if they need a refresher? I know I frequently need reminding, and constantly return to the source to verify or disprove what I think is correct.
Might I also add that following the guidelines not only helps with quality, but it also helps with readability for those times when "patch?" is uttered? If I feel like I am going to have to spend a lot more time with reading through the code in order to make a change or three (because of the lack of coding style or following the guidelines), I am less likely to go through the effort, especially if I feel like my effort won't be accepted or maintained.
I have heard it said that working in contrib is a way to be involved with Drupal without having to comply with the coding guidelines. For me, however, it's the starting point of what my code should look like and strive to achieve.