Linked by Thom Holwerda on Tue 15th Jan 2013 21:24 UTC
Thread beginning with comment 548941
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
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 
I had a computer programming teacher that used to prefer:
a = a + 1;
to
a++;
in the name of readibility!!!
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





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