A good sign...
One of the best indications of the quality of a programmer is their coding practice. Some of the best programmers I've known produce code almost mechanically in a consistent format which is very easy to read.
Among their practices:
Matching curly brackets in the same column. Of course an opening curly bracket on its own line generates more "white space" (more on this later). However, it is overwhelmingly beneficial to be able to visually pick out matching curly brackets by simply scanning a column, instead of hunting for the opening bracket in some random column at the end of an 'if' or 'for' statement. What's more, these outstanding programmers -- when you watch them type -- would type the curly brackets together, so they don't waste time later resolving compile "end-of-file" errors. They do the same with parentheses.
White space. I learned from an ad copy guru that the human eye and brain likes white space. Dense ads usually repel the eye. The same goes for code, and these outstanding programmers know this. They put in ample white space that makes their code comfortable to look at, and easy to read and to understand.
Also, the white space is not arbitrary -- it serves a purpose. For example, lines of code for, say, initializing a set of related working variables are like a paragraph, and should be written as a block of code with a blank line before and after. This formatting conveys a meaning that makes it easier for the next programmer to understand what is going on.
Another place where white space is desirable: after commas, and before and after operators. These spaces are akin to spaces between words. Itcertainlyisharderforyoutoreadthiswithoutspaces,isitnot?
And yes, an opening curly bracket should be on its own line. Not only is it easier to match with its mate, the white space is also naturally appealing to the eye.
Methodical coding. This practice is closely linked to a disciplined process for designing software. These outstanding programmers ask and answer the same series of questions before writing code. "What objects are involved?" "What do each of these objects know about?" "What do they do?" "What information do they share?"
This process is reflected in the code construction. First header code is written to define objects (of course, when an object class is coded, the opening and closing curly brackets are typed together). Then the data members are added. Then the access methods. Then the implementation of the methods. Aside from top-down psuedo-code during design, code is written and tested bottom-up. Magically when the coding reaches the top, the vast majority of it works, and is very comprehensible.
Refactoring and reformatting. Most legacy code is messy. Outstanding programmers don't just leave it that way -- they leave it in a readable format for the next programmer (I'm not talking about religious wars about style here, but rather about making really messy code look professional). Outstanding programmers will tell you that messy code wastes time, and the small time investment it takes to clean it up more than returns the investment.
A more extreme measure in this direction is refactoring -- actually changing the code, often to hide irrelevant detail. Outstanding programmers know that the human mind can hold only so much detail at once, and the cost of code maintainence is vastly reduced by allowing only a certain amount of detail to be in scope. Thus, rewriting code that does five things at once so instead it takes five independent passes -- in the end -- saves time, effort and money. So does replacing 27 arguments with a few "parameter" or "context" objects. So does eliminating global variables.
So if you're thinking of hiring a programmer, an excellent indication of the person's skills is the quality of the source code they produce. Excellent code, excellent programmer.
Among their practices:
Matching curly brackets in the same column. Of course an opening curly bracket on its own line generates more "white space" (more on this later). However, it is overwhelmingly beneficial to be able to visually pick out matching curly brackets by simply scanning a column, instead of hunting for the opening bracket in some random column at the end of an 'if' or 'for' statement. What's more, these outstanding programmers -- when you watch them type -- would type the curly brackets together, so they don't waste time later resolving compile "end-of-file" errors. They do the same with parentheses.
White space. I learned from an ad copy guru that the human eye and brain likes white space. Dense ads usually repel the eye. The same goes for code, and these outstanding programmers know this. They put in ample white space that makes their code comfortable to look at, and easy to read and to understand.
Also, the white space is not arbitrary -- it serves a purpose. For example, lines of code for, say, initializing a set of related working variables are like a paragraph, and should be written as a block of code with a blank line before and after. This formatting conveys a meaning that makes it easier for the next programmer to understand what is going on.
Another place where white space is desirable: after commas, and before and after operators. These spaces are akin to spaces between words. Itcertainlyisharderforyoutoreadthiswithoutspaces,isitnot?
And yes, an opening curly bracket should be on its own line. Not only is it easier to match with its mate, the white space is also naturally appealing to the eye.
Methodical coding. This practice is closely linked to a disciplined process for designing software. These outstanding programmers ask and answer the same series of questions before writing code. "What objects are involved?" "What do each of these objects know about?" "What do they do?" "What information do they share?"
This process is reflected in the code construction. First header code is written to define objects (of course, when an object class is coded, the opening and closing curly brackets are typed together). Then the data members are added. Then the access methods. Then the implementation of the methods. Aside from top-down psuedo-code during design, code is written and tested bottom-up. Magically when the coding reaches the top, the vast majority of it works, and is very comprehensible.
Refactoring and reformatting. Most legacy code is messy. Outstanding programmers don't just leave it that way -- they leave it in a readable format for the next programmer (I'm not talking about religious wars about style here, but rather about making really messy code look professional). Outstanding programmers will tell you that messy code wastes time, and the small time investment it takes to clean it up more than returns the investment.
A more extreme measure in this direction is refactoring -- actually changing the code, often to hide irrelevant detail. Outstanding programmers know that the human mind can hold only so much detail at once, and the cost of code maintainence is vastly reduced by allowing only a certain amount of detail to be in scope. Thus, rewriting code that does five things at once so instead it takes five independent passes -- in the end -- saves time, effort and money. So does replacing 27 arguments with a few "parameter" or "context" objects. So does eliminating global variables.
So if you're thinking of hiring a programmer, an excellent indication of the person's skills is the quality of the source code they produce. Excellent code, excellent programmer.
posted by John Keklak at
8:00 AM
0 Comments:
Post a Comment
<< Home