To me this is a coding horror, and to you? [modified]
-
cpkilekofp wrote:
Excuse me, sir, but the original coding horror in this thread is a C# coding horror, not a C coding horror,
The original post was a C coding horror:
geoffs wrote:
So, in reviewing a coworker's code I come across the following line:
m_boolVar = (intVar == 0 ? false : true) ;Yes, parenthesization and spacing exactly as shown above. Were it my code, it would have been written as:m_boolVar = intVar != 0; // (corrected from == 0 by GDavy -- I typed too fast!...or if I was feeling in a bit more perverse mood:m_boolVar = !!intVar;There were much bigger fish to fry in this code, but there are times when I just can't let things like this go by. These things are like misspelled words that shout out at me from among the surrounding text.Although the first two lines of code could also be valid C#, the third one can't be valid C#.
cpkilekofp wrote:
Additonally, I based my comments regarding your statements about coding standards on what exactly you wrote
My coding standards are those I have written one or two posts ago.
cpkilekofp wrote:
In general, the comments you've made on this topic are in line with what I call "C bigotry", an attitude that naturally comes to most good C programmers (I was most definitely guilty of it when C was my primary development language).
I'm actually more guilty of C++ bigotry. I seldom use classes (90% of my classes are Class-Wizard-generated GUI classes), but I'm very fond of function pointers and templates.
cpkilekofp wrote:
back when I was using C regularly, we had macros almost identical to yours to convert integers to true/false when we were building files for processing by, say, COBOL mainframe programs that looked for 0 or 1 as false or true (about 17-18 years ago)
Wow. I was 2 years old back then.
cpkilekofp wrote:
perhaps, your experience in different arenas of development seems to not be as widespread as mine
Agreed. I'm just a college student.
If you can play The Dance of Eternity
I should add, for fairness, that many of those "dim bulbs" I referred to are, in fact, sophisticted experts in their own fields...but they are not computer scientists. FORTRAN, the first high-level programming language, was created so that scientists could write complex calculations without having to learn anything about the inner workings of the computer they were using for the calculation. COBOL was created with a similar intent for business and administrative purposes. C was created so that a portable language existed for computer experts that allowed one to program directly on the computer without having to use assembly language. In fact, some of the dialects of C I used in my early career contained primitives for directly address CPU registers, and most of them contained facilities for allowing in-line assembly language blocks; I may be wrong, but I doubt that you've had a use for either of these facilities in your academic career to date :)
-
I should add, for fairness, that many of those "dim bulbs" I referred to are, in fact, sophisticted experts in their own fields...but they are not computer scientists. FORTRAN, the first high-level programming language, was created so that scientists could write complex calculations without having to learn anything about the inner workings of the computer they were using for the calculation. COBOL was created with a similar intent for business and administrative purposes. C was created so that a portable language existed for computer experts that allowed one to program directly on the computer without having to use assembly language. In fact, some of the dialects of C I used in my early career contained primitives for directly address CPU registers, and most of them contained facilities for allowing in-line assembly language blocks; I may be wrong, but I doubt that you've had a use for either of these facilities in your academic career to date :)
Hey, you two are really keeping this thread going! Wow. Meanwhile, as an aside, modern C and C++ compilers still provide the capability for inline assembler code (the MS compiler defines __asm as the keyword for doing this, other compilers may use asm, _asm, etc). The ability can come in handy for performance critical areas if you don't care about portability across processors. I'll also note that the quality of code put out by modern compilers is making the usage of inline assembler not the necessity it used to be (depending on the application, of course).
-
First, let me say that the code excerpt below is not an egregious violation (and maybe not a violation at all), but it is a coding horror for my programming style and I am curious as to what the others here think about it. So, in reviewing a coworker's code I come across the following line:
m\_boolVar = (intVar == 0 ? false : true) ;Yes, parenthesization and spacing exactly as shown above. Were it my code, it would have been written as:
m\_boolVar = intVar != 0; // (corrected from == 0 by GDavy -- I typed too fast!...or if I was feeling in a bit more perverse mood:
m\_boolVar = !!intVar;There were much bigger fish to fry in this code, but there are times when I just can't let things like this go by. These things are like misspelled words that shout out at me from among the surrounding text.
modified on Tuesday, September 16, 2008 3:02 AM
-
That's what people are always saying and perhaps rightfully so. However, coming from a background of programming stemming from the mid-70's when I had 4KB of memory to program with and compilers that weren't as optimizing as today's, conciseness was a virtue. After so many years it has become a habit but hopefully not to the point where I am so concise that I generate obfuscated code. For me, verbose code is actually painful to read so maybe it works both ways. And maybe there is no absolute wrong or right in this case either...
heh Actually, I blame people like for cryptic names of C++ functions... I know a few decades ago consiness was important, but I don't like that in C++ programmers still do this, even though you can easily use self explaining names these days and aren't limited by memory size.