If you were asked to measure different programming styles what would you measure?
If you were asked to measure different programming styles what would you measure?
By "programming style", do you mean "code style", as in "how much you indent each line, where you place braces, and if you put spaces after parenthesis or not", or "the overall approach to the design and implementation of a software project", or perhaps something else?
The first one is pretty meaningless to measure.
The second is pretty hard to measure - one metric would be "how many defects per man-month", perhaps with additional difference in weight for different types of defects [for example customer found, found in internal testing, system crash, application crash, cosmetic].
If you are asking for something else, then please be more precise in what you ask about.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
1) The ability of other programmers, regardless of their experience, to quickly and more correctly, understand the code involved, when compared to other programming styles.
2) Being able to see a larger number of rows of code, on a page, as well as longer lines of code,
All this in a font size that is easily readable, not insanely small.
3) Space saving:
That's why I dislike the "let's indent each level of code by 10 spaces!" style - wastes horizontal space, and the "student style", where every opening brace has to be on it's own line - that strikes me as both condescending "look, I'm dumb as a brick and can't be trusted to type an opening brace", as well as wasting vertical space on the monitor.
I like a space before any operator, and after it as well. Just offsets and highlights it, nicely.
I don't believe a parenthesis needs a space before or after it, unless it is code requiring multiple and complex parenthesis sets, in the same line of code. Then it's helpful.
4) A certain straight forward elegance. Student style doesn't have it. I like K&R's style, liked it from the first time I saw it, and I like it still all these years later.
I've never seen anyone that indents 10 spaces? I use a tab and set my IDE to make tabs 4 spaces wide (the default on mode IDE's I've seen).
I absolutely despise code that uses those old 70's style braces that don't line up! It makes it a hell of a lot harder to read. With monitor and font sizes these days, there's no way you can use the excuse of not being able to see enough code on the screen at one time.
Exactly.
I prefer spaces between parenthesis like printf( "Hello world" ); but not having spaces doesn't bug me nearly as much as not lining up braces.
Yuk.
>I absolutely despise code that uses those old 70's style braces
>that don't line up! It makes it a hell of a lot harder to read.
A good programmer should be able to read any style as long as it's consistent. Rather than complain about a style, why not use it for a month or so to get used to it? Then you won't have as much of a problem with readability.
>1) The ability of other programmers, regardless of their experience, to quickly and more
>correctly, understand the code involved, when compared to other programming styles.
That's probably the best measure of style, but it's also the hardest one. You have to get a group of programmers to review the code.
>2) Being able to see a larger number of rows of code, on a page, as well as longer lines of code
I disgree. Compact code doesn't equate to good code.
>3) Space saving:
There's no point saving space if you don't need to. Likewise there's no point wasting space if you don't need to. You need to back this one up with a good reason.
>4) A certain straight forward elegance.
How would you measure elegance?
My best code is written with the delete key.
Why don't you like it? Are you just talking about functions or any compound statement?
I agree with this one, but not because of readability. Pretty printers and formatters tend to choke on this style and fail to produce the requested format.
>Readable code gives priority before shorter and more compact code!
Consider the advice I gave to cpjust. Neither of the styles you gave as bad examples lack readability. The problem is on your end, not being familiar enough with them to brainparse the code just as easily as you do your own style. What do you think of this one?
Code:void foo() { // code }
My best code is written with the delete key.
That one is a little better, but it's still bad.
The reason I think this one lacks readability:
is because when people write their function braces like that, they also write their if, for, while and all other braces like that and it clutters up the screen too much. If you have other stuff on the same line as a brace and you're scanning through the code quickly to find a specific piece of code or just trying to get a quick summary of the logic, it's easier to miss the brace than if it was on a line by itself. Basically it helps space out the code a bit more so it isn't one solid block of text on your screen.Code:void func() { }
>That one is a little better, but it's still bad.
Why? It has consistent indentation, the blocks are well defined, and the braces are on a line by themselves.
>it's easier to miss the brace than if it was on a line by itself
That would be a reasonable argument if the code had no indentation.
>Basically it helps space out the code a bit more so
>it isn't one solid block of text on your screen.
One solid block of text? Are you sure you're not exaggerating just a little bit? If it's really as bad as you suggest, moving the opening braces to a line on their own clearly won't fix the problem.
My best code is written with the delete key.
I don't pay any attention to the braces when I'm reading the code, it's all about following the indentation. I certainly don't have any kind of mental "count" of the current nesting depth of the code based on the brace count.Code:if ( something ) { doAbit(); ofThis(); } else { doSomeMore(); ofThat(); }
I generally assume that if the programmer cared enough to make the indentation correct, then the braces are going to be in the right place as well (and therefore of little concern).
For the most part, braces are just syntactic crumbs for the compiler to chew on to make it easier to parse the code. We humans are perfectly able to figure out the flow without braces at all, eg.
From a human perspective, there's been no loss of information. All the detail needed to still work out what's going on is still there.Code:if ( something ) doAbit(); ofThis(); else doSomeMore(); ofThat();
Or put another way, if you can't do this to your code, and have it still make sense to your readers, then it's poorly formatted code IMO. Code which forces me to mentally track the braces is just too much hard work.
Because braces add little to my understanding of the code, I like to tuck them away so they provide minimal visual intrusion on the actual code which contains what's really going on.
With a smaller font, I can also use this style
Even though the braces have undeserved prominence all of a sudden, the extra vertical white-space on a smaller text size can certainly help with program clarity.Code:if ( something ) { doAbit(); ofThis(); } else { doSomeMore(); ofThat(); }
But as ever, it's the indentation which tells me what's going on, not brace counting.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
I prefer symmetrical braces to K&R because I guess it's easy to let yourself naturally spot the symmetricality in the text, and deduce what is actually relevant.
But it's not like I'd be upset if I had to work on K&R code.
Indenting braces with the code, however, makes my brainparser choke.
Last edited by robwhit; 01-09-2008 at 03:26 PM. Reason: sp
It's just my individual opinion and coding style.
Still, usually when people write with
Typically the code is messy. Still readable, but messy.Code:void foo() { }
When people do
It's usually clean. I prefer clean style over everything else, because it makes the code extra readable.Code:void foo() { }
I know. Maybe it doesn't apply to the above example as much, but it could apply to:>Readable code gives priority before shorter and more compact code!
Consider the advice I gave to cpjust. Neither of the styles you gave as bad examples lack readability. The problem is on your end, not being familiar enough with them to brainparse the code just as easily as you do your own style.
In which case it's better to write:Code:void foo() { something; something; something; something; }
Yes, it takes more lines, but it's more readable.Code:void foo() { something; something; something; something; }
It's even scarier thanWhat do you think of this one?
Code:void foo() { // code }
Because the blocks should be put on the same level as the so called block element.Code:void foo() { }
As you can see, it really defeats the purpose of the indentation because the code is on the same level as the { and }.
To me, that's just ugly and messy and less readable.
It's all about the indentation, though--it's what makes code readable. But the style of where putting the braces can help make the code even more readable, but it's coding style and we are free to choose whichever ones we want.
And btw, braces can be important to know what code the block belongs to, not just the indentation. In big loops, I find it easier to just search for the { and } to see where it begins and ends. That's also, I'm guessing, why I like the { on a separate line.
If the only thing that matters is the indentation, then why not save even more space and do this:
Code:int func() { if ( something ) { call_func(); } else { call_func2(); } return 0; }
To satisfy everybody, the board software might have code reformaters where you can define your own styles.
What if I like completely random spacing because that would keep me alert and awake?
I might be wrong.
Quoted more than 1000 times (I hope).Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
>then why not save even more space and do this:
As long as you're consistent, no problem. Though you would be actively pursuing unreadable code by choosing a style that isn't in common use. For C it seems like the majority of programmers have settled on either a K&R variant or Allman.
My best code is written with the delete key.