Linked by Thom Holwerda on Tue 15th Jan 2013 21:24 UTC
General Development "I was really excited to write this article, because it gave me an excuse to really think about what beautiful code is. I still don't think I know, and maybe it's entirely subjective. I do think the two biggest things, for me at least, are stylistic indenting and maximum const-ness. A lot of the stylistic choices are definitely my personal preferences, and I'm sure other programmers will have different opinions. I think the choice of what style to use is up to whoever has to read and write the code, but I certainly think it's something worth thinking about. I would suggest everyone look at the Doom 3 source code because I think it exemplifies beautiful code, as a complete package: from system design down to how to tab space the characters." John Carmack himself replies in the comments.
Thread beginning with comment 548941
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Good article
by Laurence on Wed 16th Jan 2013 00:02 UTC in reply to "Good article"
Laurence
Member since:
2007-03-26

Having programmed in both, I they both have pros and cons.

The real problems are:
1: badly formatted code,
2: lack of naming conventions,
3: and bad program design

1
--
Badly formatted code will make even the most readable of languages a struggle to follow.

2
--
It doesn't matter how well you format your code, if your function / variable names are badly chosen (eg abbreviated names that mean nothing to anyone but the developer) and there's no clear naming convention, then it can be a tough job understanding what the routine does.

I will also add, overly verbose names are bad too (I have one colleague who uses entire sentences in their function names. While it's helps explain what the function does, it makes code readability more challenging).

3
--
Bad program design is a more subjective topic. Most (if not all) developers roughly agree on indentation; and naming conventions only have to be readable, concise and consistent. Not everyone agrees on the specifics of naming conventions, but as long as those 3 criteria are met, then anyone new to the code can quickly understand the standards applied to that particular project.

However bad program design is about the code design of the code - when to you objects, functions, iteration and so on. Sometimes application performance is paramount, which often means writing clever routines in a manner that isn't ideal for a human reading back. Other times you'll be writing a program which isn't going to tax the processor much, so you can afford to opt for readability over performance (Sometimes you're lucky and the optimised code is also the most readable code).

Then you have people using obscure language features or unpopular features (goto is a great example of that. But thankfully there's very few occasions when a goto is the better method of writing a routine).

And after all that, you have the topic of code separation (eg using MVC's in web development to keep server side code separate from HTML).

----------

At the end of the day, it doesn't really matter whether your language uses English words or braces - a good developer can make their code readable.

But also, a lot of it comes down to practice. If you've never spent any time developing in C-derived languages, then the C syntax will naturally look a mess. But most developers get used to it and even come to love braces (that certainly happened to me).

Reply Parent Score: 3

RE[2]: Good article
by ebasconp on Wed 16th Jan 2013 01:25 in reply to "RE: Good article"
ebasconp Member since:
2006-05-09

I had a computer programming teacher that used to prefer:

a = a + 1;

to

a++;

in the name of readibility!!!

So, "readable code" is a very subjective term and in this case, if my teacher could not read the "++" thing... we have a problem!

Reply Parent Score: 2

RE[3]: Good article
by WorknMan on Wed 16th Jan 2013 02:22 in reply to "RE[2]: Good article"
WorknMan Member since:
2005-11-13

I actually prefer the first way myself, even though I can read the second. In general, I don't mind code that's a little more verbose, if it's easier to read.

Obviously though, there is a tradeoff between readability and verbosity; if you're using 30 lines of code to do something that could be done in 3, you could probably do better. On the other hand, if those 3 lines of code look like modem line noise on a terminal (as many perl scripts seem to end up looking like), I'd rather have the 30 lines ;)

Reply Parent Score: 3

RE[3]: Good article
by galvanash on Wed 16th Jan 2013 02:54 in reply to "RE[2]: Good article"
galvanash Member since:
2006-01-25

I had a computer programming teacher that used to prefer:

a = a + 1;

to

a++;

in the name of readibility!!!


If it is purely a readability argument, I see no reason to not use the increment operator, as long as it is alone or just being used in a loop construct. Throwing it into an array index or dropping it into a computation is confusing and dangerous.

Your teacher may have just been trying to avoid having to deal with explaining prefix vs postfix increment, how they evaluate, and all the confusion that usually leads to with a newish programmer. Sometimes teachers do things that seem silly and pointless when your still green around the ears but 20 years later you go "yeah, I get it now"...

Edited 2013-01-16 02:56 UTC

Reply Parent Score: 3

RE[3]: Good article
by renox on Wed 16th Jan 2013 09:16 in reply to "RE[2]: Good article"
renox Member since:
2005-07-06

Probably because he came from a Pascal background, in many case "readability" means "what I am used to read"..

I have a special thing for "a += 1;" myself: quite short and doesn't have the pre/post issue of "++".

Reply Parent Score: 2

RE[3]: Good article
by tylerdurden on Wed 16th Jan 2013 18:33 in reply to "RE[2]: Good article"
tylerdurden Member since:
2009-03-17

There is a very big difference between "not being able to do something" and "preferring something else."

a = a + 1 has little ambiguity to it, whereas a++ may have a rather ambiguous behavior: i.e. When does the value for a get updated? Is it implementation specific? etc, etc.

Reply Parent Score: 2