[methodin]

These 12 points seem to be the most insignificant things you can think about your code. Indentation? Camel case? Come on... mastering WRITING code will not make you a good coder. It will make your code consistent, I'll concede, but there's nothing stopping your from writing consistently bad code that looks good. Wouldn't it be more fruitful to think things like: 1) Why did I write this code as one function? 2) Should I not write this query in a loop? 3) How much memory will this array take to store? 4) Will I understand this code 3 months from now? 5) Is this code readable without comments 6) Would commenting this block help the reader understand my intentions? 7) Should this be a class, and if so, how complex will it be? 8) Can I make this code reusable?

[apaprocki]

The two go hand-in-hand. Writing articulate easy-to-read code does not mean it precludes thinking about the things you mention. You could be the best (according to your criteria) coder in the world, but if your code is unreadable, it will quite literally waste others' time. This might not seem like a big deal with a smaller project, but scale to something the size of the Linux kernel or larger and it begins to become an issue.

http://www.kernel.org/doc/Documentation/CodingStyle

[methodin]

I've rarely seen such poor code visually that it made it hard to follow - except in the rare case where someone commits line breaks incorrectly. Camel-case, underscores, indentation etc.. do not vary so widely as to prevent me from understanding code. What does prevent me from understanding code is 5-10 nested if blocks and insane logic checks without commenting.

Have you actually experienced a coder that writes good code but writes it in a manner that prevents you from understanding it? I'd love to see some actual code samples.

[rcfox]

> What does prevent me from understanding code is 5-10 nested if blocks and insane logic checks without commenting.

What's worse is multiple nested levels of #ifdef. Not only is it hard to tell how the code flows, but you can't even be sure it's all being compiled!

I work with code like this so frequently that I actually got around to learning elisp so that I could write a function in Emacs to highlight the nested levels of #ifdef. I have a black background, so each nested level increases the brightness.

(I should really get around to pulling that code off of my computer at work and putting it up for everyone to use...)

[shabble]

That code sounds pretty interesting, especially if it's adaptable to arbitrary open/close sequences

    if (.*?) { 

vs

    #ifdef .* ... #else ... #endif

I'd be interested in seeing it, even if it's a pastebin/gist dump that needs some cleanup.

[rcfox]

Unfortunately, it's only for #if .* ... #el.* ... #endif. I didn't want to write that much of a parser, so I just push the line number onto a stack if I see a line like /^\s*#if/.

I guess Emacs is using some kind of parser to do syntax highlighting, right? I wonder if it's possible to tap into that...

[shabble]

Yeah, I'm pretty sure it does, although I've never poked deeply enough / understood elisp well enough to know exactly how it does it.

Swapping out those regexen you have wouldn't be too much of a challenge, I don't think, at least for a first shot at it.

I'm more interested in the general structure of managing the counter, applying the various faces to lines, etc.

My email is in profile if you want someone to attempt to clean it up a bit (insofar as I'm capable of doing so) :)

[dustingetz]

as long as the code isn't deliberately formatted poorly, i don't care, not even a bit. besides our codebase we have a large set of dependencies, and we read and maintain dependencies all the time. whether their coding style is consistent with mine is irrelevant, I slog through it and stfu and get my job done.

[casenelson]

This is a great comment. I worried that my example was too simplistic, it's difficult to bring up design decisions (as opposed to coding style decisions) without context. For many of my questions, you'll write them down, understand them and move on to deeper questions. However, they weren't all about consistency. I think naming is particularly important, drives design, and is often overlooked.

But the exercise shouldn't stop there, as your program develops questions like yours should be asked and understood and defined. The more questions you can ask yourself, the better you'll understand your thought process.

New developers might not get far past my list. Most devs might ask some but not all of your questions. The best developers will realize more fundamental questions to ask about their decisions. Hopefully everyone can learn something new by asking those questions.