|
But I think the core concepts are Consistency and Clarity of Intent, the points above are mere means to achieve that.
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
blog: TDD - the Aha! | Linkify!| FoldWithUs! | sighist
|
|
|
|
|
Marc
|
|
|
|
|
OK for people like you, what makes it more UNDERSTANDABLE?
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
blog: TDD - the Aha! | Linkify!| FoldWithUs! | sighist
|
|
|
|
|
peterchen wrote: OK for people like you, what makes it more UNDERSTANDABLE?
Plain English. OK - that should have a sick joke icon.
|
|
|
|
|
That's the pinnacle of lack of taste! 
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
blog: TDD - the Aha! | Linkify!| FoldWithUs! | sighist
|
|
|
|
|
I totally agree with Marc. Less is ALWAYS better!
|
|
|
|
|
I like that Marc...
http://troysmusic.com
|
|
|
|
|
Having read the posts (almost !!) i'd like to share some points.
Code readability is not based on a single factor but it relies on all of the above mentioned to help the reader understand what the code does and how it does it.
Let's take a Class module for example.
A CLASS should have remarks to explain what it does.
..> The variables and functions (and subs too) should have good and informative names.
....> The names should have informative prefixes to help disnstinguish them.
....> The routine code should be compact, well-structured and small (relativelly).
......> Whitespaces should be used.
........> Brief inline remarks should at least inform the reader of what's going on.
........> Execution, calls, logic should be commonly used without any backdoors, workarounds, or "my own cooking recepies" type of thinking.
All these rules are a MUST when there are more than ones self working on code. Of course, if your not programming for open-source (not necessarily GPL  ) or working solo, then all the above are optional.
|
|
|
|
|
I am not a great programmer  but I agree that multiple answers are in order.
djj
|
|
|
|
|
In the question of readability, the most important criteria I find is good use of whitespace. I don't mean someone double spacing every line or some such. Grouping things with whitespace makes it all so much easier to deal with. I commonly find that most of the ancient F77 code I'm forced to read and update used none of these techniques.
Whitespace in code should be much like paragraphs in papers and books. It simply gives you some context as to where to break thoughts. I can more quickly get around someones poorly thought out structures or pidgen coding dialect easier than a completely lack or overuse of whitespace. I can read through and create useful comments where they don't exist if the whitespace breaks up thoughts in the code. Good whitespace use ends up being a part of common coding patterns and practices as everything is broken up. As for limits on file, class and method sizes? You should be able to read any length of file without confusion as long as there is good whitespace. And since engineers and scientists end up writing most F77 code, I have become quite proficient at reading past and/or correcting spelling and grammatical errors, which isn't to say I don't make them myself.
|
|
|
|
|
Very True.
It's not only an issue of grouping things with whitespace, it's also proper use of indentation. It is easier to follow code with If...End, Do While, and any controls with multiple lines of code being used, when the inner lines are indented. It's easier to troubleshoot nested code when you can visually tell where it starts and ends.
|
|
|
|
|
God yes, I have to do some work with some old store procedures in Oracle and some of them were written by a mouth breather that doesn't indent at all. It's so hard to follow.
|
|
|
|
|
If the coding practices are well thought out and adhered to, all of the other issues can be resolved with refactoring tools. To my mind, coding practices define naming conventions (item 1), use of logic patterns (item 2), commenting requirements (item 3), whitespace (item 5), size limits (item 6), and spelling (item 7).
Software Zen: delete this;
|
|
|
|
|
- I couldn't agree more.
- Adherence to Common coding practices just about covers the rest of the choices!!
void izmoto(char* szKwazi);
|
|
|
|
|
You got it!
http://troysmusic.com
|
|
|
|
|
The technique I used to evaluate this was, if the factor in question were of pathetic quality and the rest were great, what effect would it have on the overall code quality? Eg: what if the code is neatly laid out, variables are named well, etc, but there are no comments?
When I used to work for [payment processing company that will remain nameless], I came across code littered with variable names like ntl and icpt. I asked the cretin who wrote the code what they represented, and he said they were notional and intercept. Quite understandably, I didn't ask him what cnt stood for.
I find that intuitive naming comes out on top.
Cheers,
Vikram.
|
|
|
|
|
A clear and good nomenclature aides and facilitates an interesting read for a peer developer without creating any boredom.
Vasudevan Deepak Kumar
Personal Homepage
Tech Gossips
A pessimist sees only the dark side of the clouds, and mopes; a philosopher sees both sides, and shrugs; an optimist doesn't see the clouds at all - he's walking on them. --Leonard Louis Levinson
|
|
|
|
|
This is a tough poll to answer, it's hard to pick a top answer.
However, I agree with 'intuitive names', the reason being that if good names are chosen for variables, methods, and classes, then some poor choices for structure, logic and design were probably evluated and discarded (or refactored) because they resulted in confusing names.
The confusing names should have been a clue that something was wrong with the design. thus, if properly done, 'intuitive names' should have resulted in better clarity in other areas as well.
|
|
|
|
|
Well expressed, was just thinking the same thing  .
Wout
|
|
|
|
|
may sound stupid, but its a fact...
|
|
|
|
|
Which suggests a possible improvement to the surveys: Randomise the order of the answers.
|
|
|
|
|
Or get rid of them entirely.
|
|
|
|
|
I disagree. The results are exactly as I would have weighted them in terms of what is most important. They probably should have not just written down the most important ones they could think of first, though. Yes, ideally the questions for all surveys would be shuffled in random order each time it's taken. But the Microsoft way of doing things is to rely heavily on "wizards" and drag-and-drool GUI tools. When you're not coding by hand, your flexibility is almost always limited in some way. And most of Microsoft's tightly-coupled interfaces punish those of us who like to code everything by hand.
|
|
|
|
|
All of these have significant benefits, but I have to defer to good comments as the best tool for making code maintainable. If I can read a short comment block that explains the purpose of the following code block, it's the best possible head-start.
Intuitive variable names is great; very high on my list, in fact. But I don't want to have to even read the code if I'm not in the right place. I shouldn't have to analyze code, at any level, to determine what the purpose of that code is.
Good coding practices and standards is also great. I don't want to have to weave through a mess of spaghetti just to end up pulling out my hair when it's all done. (Far too little now, as it is, anyway!) But again, do I need to read this code?
I'm my worst critic. I'm working solo on a huge project, and I'm often updating or inserting comments because I want to be able to quickly determine what code I'm looking at, and second, to determine how it works.
|
|
|
|
|
It is not easy to select one but most acceptable when we have one option clear comments that explain every thing.
Whatever you do will be insignificant, but it is very important that you do it
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
