in reply to Prgramming vs. Coding

In the same way, the best coders seem to absorb sections of code at one gulp.

I might comment more later, but I just wanted to thank you for that nugget. I find code hard to read when it is spread out too far. The oft-praised practice of putting your braces on lines by themselves, separating your blocks with blank lines, and putting multi-line comments all over the place yields code that I have a terrible time following. I have to stop and read it a line at a time, remembering more and more lines until I can collapse them into a concept.

I love a nice tight subroutine whose entire code fits on a 40x80 screen. I like end-of-line comments that don't break up the code and trip up my eye. Complex things should be explained outside the code of the subroutine.

These attitudes of mine are always interpretted as some rebel hacker sickness. My primary job for years was reading other people's code. The hardest to read code is poorly designed code. But the number two worst problem is code that is so broken apart that you don't have a complete, useful concept in one piece. Adding vertical white space is a good idea if you have a 300-line routine. A much better idea is to factor out the conceptual chunks into reasonably-sized routines.

Yes, if you go looking at the code I post on PerlMonks you will probably find much code that is too compact. That is the fun of Perl and PerlMonks. I avoid many forms of compactness in production code because I know the next guy might not be a great coder. But I hate the waste of vertical space that is so often demanded.

P.S. I think of "coder" as a term for a warm body that can produce functional code if you don't require any deep thought, design work, etc. from them -- just the opposite of your take on things. The use of "coder" as a compliment seems more a slang and usually requires an extra adjective. But that is probably just me being out of touch. :-}

        - tye (a heretic, as usual)

Replies are listed 'Best First'.
My Two Penneth
by frankus (Priest) on Oct 06, 2000 at 15:40 UTC
    Contrarily, I percieve a coder as one producing results in a given language: a programmer writes programs in several languages but is oft ignorant of a language's idiom. Either of these individuals may be prone to haste.

    I disagree with some comments concerning code aesthetics although I whole-heatedly cheer the comments about concise subroutines and your comments about abstraction rather than monolithic code.

    I gained a lot from Kernigan and Pike's book Practice of Programming that indicates that code beautification is irrelevant with tools like emacs to reformat to coders preference; but it is confusing when diffing versions of the same file indented differently.

    I suppose in the final analysis being a programmer or coder, is based solely on the individual's perception.

    Brother Frankus.
      Given, my most recent experiences this is what I now believe, coders are what one book I've recently read defines as language bigots: people who don't ask how or why, don't use design methodologies and fear CASE Tools.

      A programmer is someone who may know several languages, may prefer one, but uses whatever tools are to hand to make their job easier. Programmers may be less knowledgable about architectures or operating systems but have a good idea of what Software engineering is.

      Obviously it can be seen I am biased to one, that's because I suffer the other.

      Brother Frankus.
RE: Phrasing! (RE: Prgramming vs. Coding)
by merlyn (Sage) on Oct 06, 2000 at 18:28 UTC
    Adding vertical white space is a good idea if you have a 300-line routine. A much better idea is to factor out the conceptual chunks into reasonably-sized routines.
    I try very consciously to add whitespace between "paragraphs" in my programs, and to order the code into reasonable "paragraphs" and "subsections", usually flagged with additional comments as to the purpose of the following section. You can see evidence of this in my columns.

    I also tend to minimalize the comments to just those things that carry context. I try to let the Perl code speak for itself, and don't define anything that they can get from a perusal of the first half dozen entries in perldoc perl. But if I have an algorithm, or a dependency that wouldn't necessarily be obvious, that becomes the comment.

    -- Randal L. Schwartz, Perl hacker