[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.