Thread: Is there a way to measure programming style?

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

>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?

Originally Posted by Adak

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 disagree with that one.
There are two coding styles I don't like:
One is:

Code:

void foo() {
}

And one is:

Code:

void foo()
{ // something;
// something
}

It should be:

Code:

void foo()
{
	// something
}

Readable code gives priority before shorter and more compact code!

Originally Posted by Elysia

There are two coding styles I don't like:
One is:

Code:

void foo() {
}

Why don't you like it? Are you just talking about functions or any compound statement?

Originally Posted by Elysia

And one is:

Code:

void foo()
{ // something;
// something
}

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
    }

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

Code:

if ( something ) {
    doAbit();
    ofThis();
} else {
    doSomeMore();
    ofThat();
}

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

Code:

if ( something )
    doAbit();
    ofThis();
else
    doSomeMore();
    ofThat();

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.

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

Code:

if ( something )
{
    doAbit();
    ofThis();
}
else
{
    doSomeMore();
    ofThat();
}

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.

But as ever, it's the indentation which tells me what's going on, not brace counting.

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.

Originally Posted by Prelude

Why don't you like it? Are you just talking about functions or any compound statement?

It's just my individual opinion and coding style.
Still, usually when people write with

Code:

void foo() {
}

Typically the code is messy. Still readable, but messy.
When people do

Code:

void foo()
{
}

It's usually clean. I prefer clean style over everything else, because it makes the code extra readable.

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

I know. Maybe it doesn't apply to the above example as much, but it could apply to:

Code:

void foo() { something; something; something; something; }

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.

What do you think of this one?

Code:

void foo()
    {
    // code
    }

It's even scarier than

Code:

void foo() {
}

Because the blocks should be put on the same level as the so called block element.
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.

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?

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