Ladavac Marino once stated:

=> =Whilst the official codebase may be under the control of a select
=> =group of committers, the code should be capable of being understood
=> by
=> =anyone who is reasonably proficient with C.
=> 
=> Depends on your definition of "reasonably", Mr. Special Counselor...
=       [ML]  
=       I see no cause for name calling.

I'm sorry, I did not mean "name calling". I was making a joke
refering to the America's infamous senior public official talking
to a certain Special Counsel (or Independent Counsel).

=       And, guess what, none of these languages have the same
=       operator precedence as C/C++.  But they all have
=       parentheses.  Knowledge of operator precedence as a
=       metric of programming proficience--ludicrous.  My brain
=       would turn to pretzel if I had to know all the precedence
=       rules in all the languages that I daily have to use.

I must admit, that this is the first reasonable argument I observe
in a few days of this Battle of Giants. Mostly it looks like:

        -- I think, the code must be readable, therefore, we must allow
           for X.

        -- No, I think, the readability is very important, therefore X
           should be disallowed.

=       /* the reason for branching */
=       if ( (a * b  -  c * d) < (e / f) ) {
=               true_part();
=       }
=       else {
=               false_part();
=               more_false_part();
=       }

=       You will have noticed that I put braces around single
=       statements.  This has no performance penalty--a reasonable
=       compiler will not create a stack frame--and helps in
=       maintenance.

I'd say, I do not like this :) My first move is to remove the un-needed braces
or put `else' onto the same line as the closing brace before it (I program in 
TCL
a lot). But we all 've read enough of this already.

The discussion is no longer interesting because of its subject, but rather
because of its style. And this is a whole different branch of science...

        -mi

To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Reply via email to