C
CBFalconer
Mark said:
Any you are claiming that you don't see the equivalent of my second
example every day or more?
Any you are claiming that you don't see the equivalent of my second
example every day or more?
D
Default User
Mark said:
Well, duh, you don't TELL cow-orkers about it.
Brian
M
Mark McIntyre
CBFalconer said:
I'm saying that the examples were statistically meaningless. If you
sampled the codebase of any large programme at random, some samples will
be more spaced out than others, as a result of programmer preference,
developments in house style and probably editor technology. Two random
snippets won't tell you anything useful however.
By the way I write in style 2 pretty much exclusively, to improve
clarity. Don't you?
J
jacob navia
Mark said:
What is clarity?
It is being able to see more of the program in the screen at a given
time without having to scroll down or up...
Verbose programs that go over lines and lines need constant scrolling to
see read them.
With less verbosity and unnecessary white space, you can see
the whole function in the screen at a single page, what makes much more
to improve things that verbose line style.
As anything, this rule can be perverted too, and you get obfuscated
code.
But
if (i=foo(baz)) goo(sss);
is perfectly clear and readable to me...
S
santosh
jacob said:
It's a measure of how quickly and easily a programmer reasonably
competent in the language can understand the purport of a piece of
code.
Either extreme defeats clarity. Excessively terse code makes you waste
time figuring it out while excessively verbose code makes you waste
time ploughing through it.
Yes. This particular construct is a common idiom and is can be quickly
recognised. But imagine hundreds of thousands of lines like this, all
cramped together. Some vertical space is okay.
I'd prefer:
if (i = foo(baz))
goo(flimdiddle);
G
Gordon Burditt
Ah, obviously the two following snippets have widely differing
No: not when there are simple "LOC inflater" algorithms like
"replace every newline with 1 trillion newlines".
Remember, use of a metric for performance evaluations or payment
for work alters the result of the work next time. You need to
assume people will try to "cheat", especially if it's not illegal.
Not when you have a computer do it for you.
You might get a metric that is a little harder to cheat with
a definition like:
- Count the number of lines of code *after* running it
through GNU indent with specified command-line options.
- Lines that are empty or consist entirely of whitespace or
comments or parts of comments or empty statements do not count.
No: not when there are simple "LOC inflater" algorithms like
"replace every newline with 1 trillion newlines".
Remember, use of a metric for performance evaluations or payment
for work alters the result of the work next time. You need to
assume people will try to "cheat", especially if it's not illegal.
Not when you have a computer do it for you.
You might get a metric that is a little harder to cheat with
a definition like:
- Count the number of lines of code *after* running it
through GNU indent with specified command-line options.
- Lines that are empty or consist entirely of whitespace or
comments or parts of comments or empty statements do not count.
G
Gordon Burditt
The "line of code" is an incredibly silly measure of code complexity.
I claim that LOC is completely and absolutely unrelated to code
complexity *written by a programmer who knows what your metric is
and who knows s/he will be paid according to the metric*.
I claim that LOC is completely and absolutely unrelated to code
complexity *written by a programmer who knows what your metric is
and who knows s/he will be paid according to the metric*.
C
CBFalconer
Mark said:
No, I write in style 1 pretty much exclusively, in order to improve
clarity.
I
Ian Collins
If you have to scroll to see a whole function on any half decentjacob said:
display, your function is too long.
S
santosh
Gordon Burditt wrote:
This is good simple way to quantify code volume, but it has nothing to
do with code complexity unless you claim volume and complexity are
directly proportional.
Complexity is far more subjective that a mere count of code statements
etc. What may be "complex" to one programmer would be routine stuff for
another.
This is good simple way to quantify code volume, but it has nothing to
do with code complexity unless you claim volume and complexity are
directly proportional.
Complexity is far more subjective that a mere count of code statements
etc. What may be "complex" to one programmer would be routine stuff for
another.
J
James Kuyper
Gordon Burditt wrote:
....
The times when I've been asked by upper management to give them line
counts, it had nothing to do with determining how much anyone would get
paid, and the code had not been written with the expectation that there
would be any such a connection.
In my project, how well the program works has a lot more to do with
anyone's pay level than how big it is. If anything, a large size might
count (VERY slightly) against the programmer, by implying that the
program was overly complex for the tasks it needed to perform.
How well the program works is, in turn, less important than meeting
deadlines, as long as the code does meet it's minimum requirements by
the time the deadline arrives. Since the requirements are more easily
negotiable than deadlines, this means that meeting deadlines is the
single most important thing. I'm not happy with that fact, but I can
understand why meeting deadlines is a high priority, when several dozen
scientific teams from around the world are waiting for our programs to
work correctly before they can test whether theirs are working correctly.
....
The times when I've been asked by upper management to give them line
counts, it had nothing to do with determining how much anyone would get
paid, and the code had not been written with the expectation that there
would be any such a connection.
In my project, how well the program works has a lot more to do with
anyone's pay level than how big it is. If anything, a large size might
count (VERY slightly) against the programmer, by implying that the
program was overly complex for the tasks it needed to perform.
How well the program works is, in turn, less important than meeting
deadlines, as long as the code does meet it's minimum requirements by
the time the deadline arrives. Since the requirements are more easily
negotiable than deadlines, this means that meeting deadlines is the
single most important thing. I'm not happy with that fact, but I can
understand why meeting deadlines is a high priority, when several dozen
scientific teams from around the world are waiting for our programs to
work correctly before they can test whether theirs are working correctly.
M
Mark McIntyre
(of a style with sensible amounts of whitespace vs a style
withnowhitespaceatall)
You have a very strange idea of clarity. Do you by any chance write EC
directives in your spare time?
M
Mark McIntyre
How horribly true that is
or thereabouts... :-(
You missed out the first priority of course -coming in on budget...
C
CBFalconer
Mark said:(of a style with sensible amounts of whitespace vs a style
withnowhitespaceatall)
You have a very strange idea of clarity. Do you by any chance
write EC directives in your spare time?
Just to avoid misconceptions, here is my recommended bit:
if (i = foo(baz)) goo(flimdiddle);
which is quite obvious. goo is called if i is nonzero. There are
adequate blanks to separate ids from operators, etc.
I
Ian Collins
All fine and dandy until you want to set a break/watch point on thatCBFalconer said:
particular call to goo().
C
CBFalconer
Ian said:
I don't.
R
Richard
CBFalconer said:I don't.
Which is why it's the general consensus that your code layout is
atrocious and not to be used as a paragon of good style. Having multiple
statements on one line like this makes code very hard to read and
debug. This is never, ever a good idea.
if (i = foo(baz))
goo(flimdiddle);
Shows immediately at a casual glance without even reading the code in
detail that a logic condition can cause a subroutine call and the
maintainer might want to keep an eye there. But this has been discussed
ad-infinitum.
M
Mark McIntyre
I don't.
Which is nice for you, but a bit of a nightmare for the poor maintenance
droid who has to disentangle your code. I'm all for compactness, but not
at the expense of either ease of maintenance or clarity for less expert
programmers. Writing dense code just for the sake of it smacks of, well,
elitism.
G
Golden California Girls
Mark said:
Ah, yes, the APL one liner competition. Fun but not for serious stuff.
But that attitude of elitism has completely taken over the standards process.
In the name of allowing anything they have forgotten the cardinal rule of a good
standard. A good standard should make errors obvious if it can't make them
impossible. This is because writing the standard is done once, using the
standard is done billions of times. Fixing it in the standard prevents billions
of wasted hours of time down the road, never mind the secondary effects. But
this is the hard road to take, so it isn't done.
Perhaps if this thought was tossed in at the start of every standards committee
meeting and message, "The standard you are working on today will be used by a D
student tomorrow to secure your pension and bank account." it would give them
the proper perspective on what they are doing.
C
CBFalconer
Mark said:
Ah, but the debugger never crosses my mind, because I virtually
never use them. If it is of real use to the end user, he is quite
welcome to insert a <return> before the goo call and recompile.
My objective is to make the source code readable and sensible. It
is something like paragraphing prose. Every so often a totally
blank line appears to separate thoughts. More often the separation
is done by breaking into functions. The inline directive is very
handy for combining this with minimum function call overhead.