To me this is a coding horror, and to you? [modified]
-
cpkilekofp wrote:
but what IS the joke??
What's the need for such an abstraction as a "boolean"?
If you can play The Dance of Eternity (Dream Theater), then we shall make a band.
leonej_dt wrote:
What's the need for such an abstraction as a "boolean"?
I should think it's obvious. Booleans represent either true or false, yes or no. "Is the door open? yes." Using a boolean type, you're guaranteed that the value of an instance of that type will be one of two choices, true or false. Any other questions?
-
leonej_dt wrote:
What's the need for such an abstraction as a "boolean"?
I should think it's obvious. Booleans represent either true or false, yes or no. "Is the door open? yes." Using a boolean type, you're guaranteed that the value of an instance of that type will be one of two choices, true or false. Any other questions?
And what's the difference between an 8-bit boolean and an 8-bit char whose values are restricted to 0 and 1? I still don't get it.
If you can play The Dance of Eternity (Dream Theater), then we shall make a band.
-
And what's the difference between an 8-bit boolean and an 8-bit char whose values are restricted to 0 and 1? I still don't get it.
If you can play The Dance of Eternity (Dream Theater), then we shall make a band.
leonej_dt wrote:
And what's the difference between an 8-bit boolean and an 8-bit char whose values are restricted to 0 and 1? I still don't get it.
What does the restriction? Either the language provides facilities for doing it, or the programmer has to provide the facilities. If its in the language, it can be taught in a standard way and understood in a standard way. If the programmer provides it, the programmer has to explain it, and only those with access to the programmer or his documentation will understand it. Why else develop languages in the first place? If everyone in the world had the ability to program effectively in machine language, we'd all be doing that.
-
leonej_dt wrote:
And what's the difference between an 8-bit boolean and an 8-bit char whose values are restricted to 0 and 1? I still don't get it.
What does the restriction? Either the language provides facilities for doing it, or the programmer has to provide the facilities. If its in the language, it can be taught in a standard way and understood in a standard way. If the programmer provides it, the programmer has to explain it, and only those with access to the programmer or his documentation will understand it. Why else develop languages in the first place? If everyone in the world had the ability to program effectively in machine language, we'd all be doing that.
When I program (I don't know about other people), my priorities are, in decreasing order: 1. the program has to be as fast as possible 2. the compiled executable has to be as small as possible 3. the source code has to be as small as possible Any sufficiently good C programmer knows what the double negation does. But, if you can't quite get it, you can define a macro
#define IS_NOT_ZERO(a) !!(a)And the double negation won't bug your mind everywhere in the code. ;PIf you can play The Dance of Eternity (Dream Theater), then we shall make a band.
-
When I program (I don't know about other people), my priorities are, in decreasing order: 1. the program has to be as fast as possible 2. the compiled executable has to be as small as possible 3. the source code has to be as small as possible Any sufficiently good C programmer knows what the double negation does. But, if you can't quite get it, you can define a macro
#define IS_NOT_ZERO(a) !!(a)And the double negation won't bug your mind everywhere in the code. ;PIf you can play The Dance of Eternity (Dream Theater), then we shall make a band.
leonej_dt wrote:
When I program (I don't know about other people), my priorities are, in decreasing order: 1. the program has to be as fast as possible 2. the compiled executable has to be as small as possible 3. the source code has to be as small as possible
Nice, as long as no one will ever have to change your code again. Naturally, you forgot the fourth rule, which distinguishes the professional from the cowboy: 4. The code must be readable by someone with no more than six months of experience. 5. The code must be modifiable and extendable without a major rewrite. You see, there's no guarantee that the next person to maintain your code is as sharp on all the nuances of code as you are; in fact, in any group setting, first cuts are often written by senior programmers, while modifications are often written by juniors. And, in fact, your own observation qualities fall short: this is a C# example, not a C example. I was an expert in C programming for the first half of my career, to the point that I had the names of the standard headers and most of their standard declarations memorized. I used this trick and many others unique to C-like languages. It is, however, a cowboy trick, and if I found it in a review of your C# code, you'd be fixing it the next day. Tricks like this were often necessary in C because C didn't support booleans, but it's unnecessary in C#.
leonej_dt wrote:
Any sufficiently good C programmer knows what the double negation does. But, if you can't quite get it, you can define a macro #define IS_NOT_ZERO(a) !!(a)
Again, this is a C# example, and C# does not have macro capabilities, any more than it has pointers. Now, in some environments the skill level required is so high, and will remain so high, that you can write everything in obscure C with no indentation and the next programmer will be able to read it at a glance. Making your employer depend on this level of skill when they don't have to is a disservice to your employer.
-
leonej_dt wrote:
When I program (I don't know about other people), my priorities are, in decreasing order: 1. the program has to be as fast as possible 2. the compiled executable has to be as small as possible 3. the source code has to be as small as possible
Nice, as long as no one will ever have to change your code again. Naturally, you forgot the fourth rule, which distinguishes the professional from the cowboy: 4. The code must be readable by someone with no more than six months of experience. 5. The code must be modifiable and extendable without a major rewrite. You see, there's no guarantee that the next person to maintain your code is as sharp on all the nuances of code as you are; in fact, in any group setting, first cuts are often written by senior programmers, while modifications are often written by juniors. And, in fact, your own observation qualities fall short: this is a C# example, not a C example. I was an expert in C programming for the first half of my career, to the point that I had the names of the standard headers and most of their standard declarations memorized. I used this trick and many others unique to C-like languages. It is, however, a cowboy trick, and if I found it in a review of your C# code, you'd be fixing it the next day. Tricks like this were often necessary in C because C didn't support booleans, but it's unnecessary in C#.
leonej_dt wrote:
Any sufficiently good C programmer knows what the double negation does. But, if you can't quite get it, you can define a macro #define IS_NOT_ZERO(a) !!(a)
Again, this is a C# example, and C# does not have macro capabilities, any more than it has pointers. Now, in some environments the skill level required is so high, and will remain so high, that you can write everything in obscure C with no indentation and the next programmer will be able to read it at a glance. Making your employer depend on this level of skill when they don't have to is a disservice to your employer.
cpkilekofp wrote:
4. The code must be readable by someone with no more than six months of experience.
My code might not always be readable by someone with little experience, but...
cpkilekofp wrote:
5. The code must be modifiable and extendable without a major rewrite.
... even when I'm doing low-level stuff, I take enough care to ensure the logic of the program can be understood. [Edit starts here] If comments are not enough, I document what I'm doing, both the mathematical proof of correctness and the actual algorithm, step by step. [Edit ends here]
cpkilekofp wrote:
is a C# example, not a C example.
Excuse me, sir. You are wrong. The IS_NOT_ZERO macro is a C example, not a C# one. You can't apply the ! operator to an integer in C#. You can do that in C.
cpkilekofp wrote:
It is, however, a cowboy trick, and if I found it in a review of your C# code, you'd be fixing it the next day.
The IS_NOT_ZERO macro was a joke. I was making fun of people who can't understand what !! does to an integer.
cpkilekofp wrote:
that you can write everything in obscure C with no indentation and the next programmer will be able to read it at a glance.
I may be a cowboy coder, but I always indent my code. If my code is not clear, that might have been the result of a) intentional obfuscation b) not so obvious optimization In either case, I document what I'm doing.
If you can play The Dance of Eternity (Dream Theater), then we shall make a band.
-
cpkilekofp wrote:
4. The code must be readable by someone with no more than six months of experience.
My code might not always be readable by someone with little experience, but...
cpkilekofp wrote:
5. The code must be modifiable and extendable without a major rewrite.
... even when I'm doing low-level stuff, I take enough care to ensure the logic of the program can be understood. [Edit starts here] If comments are not enough, I document what I'm doing, both the mathematical proof of correctness and the actual algorithm, step by step. [Edit ends here]
cpkilekofp wrote:
is a C# example, not a C example.
Excuse me, sir. You are wrong. The IS_NOT_ZERO macro is a C example, not a C# one. You can't apply the ! operator to an integer in C#. You can do that in C.
cpkilekofp wrote:
It is, however, a cowboy trick, and if I found it in a review of your C# code, you'd be fixing it the next day.
The IS_NOT_ZERO macro was a joke. I was making fun of people who can't understand what !! does to an integer.
cpkilekofp wrote:
that you can write everything in obscure C with no indentation and the next programmer will be able to read it at a glance.
I may be a cowboy coder, but I always indent my code. If my code is not clear, that might have been the result of a) intentional obfuscation b) not so obvious optimization In either case, I document what I'm doing.
If you can play The Dance of Eternity (Dream Theater), then we shall make a band.
leonej_dt wrote:
cpkilekofp wrote: is a C# example, not a C example. Excuse me, sir. You are wrong. The IS_NOT_ZERO macro is a C example, not a C# one. You can't apply the ! operator to an integer in C#. You can do that in C.
Excuse me, sir, but the original coding horror in this thread is a C# coding horror, not a C coding horror, thus my comments about using booleans where you MEAN it is either true or false are appropriate, while your comments that it doesn't make a difference apply to C where booleans (at least for most of the language's lifespan) were not supported; is that, finally, clear?. Additonally, I based my comments regarding your statements about coding standards on what exactly you wrote; getting upset because I responded to, again, exactly what you wrote rather than what you actually do would seem to me to be a problem with your description. Further, I wasn't referring to your code when I commented about "indentation" - how could I, when the only piece of code from you that I saw was a single line? However, I've had to read, debug, and modify more than one piece of obscure C that made it into production in the time before code reviews became commonplace. 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). The elegance and concision of C creates in the C developer an automatic contempt for languages which lack those features, and for those who find it difficult to impossible to read C when used by one well versed in all its subtleties. Please note: 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), so I don't see your macro as a joke; however, I do view your comment as an indicator that, perhaps, your experience in different arenas of development seems to not be as widespread as mine (this is NOT a comment on your skill, just on the limited number and type of programming environments to which you have been exposed - once you reach the point where you are working with junior programmers with much less skill than you have, some of these points will not only be clearer to you, they'll seem like "common sense").
-
Megidolaon wrote:
Your code is shorter, but the other one is easier to read.
How on earth can it possibly be easier to read??? His code is a subset of the code you claim is "easier to read". In order to understand the ternary you need to understand the first expression (the condition), as well as the ternary itself, as well as the assignment operator. His code makes for less to read, and is clearer (one less step in deducing what value the variable ends up having under various conditions). Anyone who uses a ternary of type boolean is a twit!
dfgdfgdfgdgdgdgdgdgdg
-
Let me get this right, you're asking about how stupidity can exist on the internet. The only type of question more likely to get a yes answer than 'can there be anyone on the web that stupid/ignorant/obnoxious' is 'can there be anything on the web that gross/perverse/obscene'.
Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots. -- Robert Royall
Not to stray too far off topic but what's the "scandinavian language roots" you are referring to..? I'm Norwegian and have no clue what it might be.
-
Thanks for the vote of confidence! On another point, I was with you until that last statement. Wouldn't the choice of '==' versus '!=' be completely dependent on what comparison you were trying to make? Generally isn't a term I would apply here.
I agree. Rather than choose by operator preference (precedence?) :) one should define the flag that makes most sense and use whatever operators needed to get there. bool sameSize = (x*y == z*w); bool eligible = (salary >= 30000 || fortune >= 200000); bool defined = ((value ?? defaultValue) != null); ...
-
RugbyLeague wrote:
It's just different styles of programming rather than a coding horror.
If you coded "boolean_value == true" in my shop, I'd do my best to get you out of my shop as quickly as possible. Calling this convention a "style" is like calling a bum's rags "fashion."
Hey! Keep my rags out of it a***ole! :laugh:
-
Not to stray too far off topic but what's the "scandinavian language roots" you are referring to..? I'm Norwegian and have no clue what it might be.
-
Hey! Keep my rags out of it a***ole! :laugh:
dojohansen wrote:
Hey! Keep my rags out of it a***ole!
*gives him $5 to buy new clothes from a thrift* :laugh:
-
Corruption of the verb nigle.[^]
Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots. -- Robert Royall
Thanks! Interesting, and potentially good South Park material. I've got to say though that "å nigle" isn't exactly everyday Norwegian in 2008. A quick google search for "nigle site:.no" returned 15 results, in most of those it was a name, some of them were Danish texts (though on .no sites), though there was ONE page that used it as a verb: Ka du står der å nigle ætter? (What are you standing there [å nigle] after?)
-
Thanks! Interesting, and potentially good South Park material. I've got to say though that "å nigle" isn't exactly everyday Norwegian in 2008. A quick google search for "nigle site:.no" returned 15 results, in most of those it was a name, some of them were Danish texts (though on .no sites), though there was ONE page that used it as a verb: Ka du står der å nigle ætter? (What are you standing there [å nigle] after?)
Not overly surprising, the US's major wave of immigration from Scandinavia was a century ago.
Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots. -- Robert Royall
-
leonej_dt wrote:
cpkilekofp wrote: is a C# example, not a C example. Excuse me, sir. You are wrong. The IS_NOT_ZERO macro is a C example, not a C# one. You can't apply the ! operator to an integer in C#. You can do that in C.
Excuse me, sir, but the original coding horror in this thread is a C# coding horror, not a C coding horror, thus my comments about using booleans where you MEAN it is either true or false are appropriate, while your comments that it doesn't make a difference apply to C where booleans (at least for most of the language's lifespan) were not supported; is that, finally, clear?. Additonally, I based my comments regarding your statements about coding standards on what exactly you wrote; getting upset because I responded to, again, exactly what you wrote rather than what you actually do would seem to me to be a problem with your description. Further, I wasn't referring to your code when I commented about "indentation" - how could I, when the only piece of code from you that I saw was a single line? However, I've had to read, debug, and modify more than one piece of obscure C that made it into production in the time before code reviews became commonplace. 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). The elegance and concision of C creates in the C developer an automatic contempt for languages which lack those features, and for those who find it difficult to impossible to read C when used by one well versed in all its subtleties. Please note: 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), so I don't see your macro as a joke; however, I do view your comment as an indicator that, perhaps, your experience in different arenas of development seems to not be as widespread as mine (this is NOT a comment on your skill, just on the limited number and type of programming environments to which you have been exposed - once you reach the point where you are working with junior programmers with much less skill than you have, some of these points will not only be clearer to you, they'll seem like "common sense").
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
-
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
LMAO...it had never occurred to me to compile "m_boolVar = !!intVar;", but you're right, C# rejected it because the bang operator is not valid for integers. So it is a C coding horror. Your coding standards as originally stated, 1. the program has to be as fast as possible 2. the compiled executable has to be as small as possible 3. the source code has to be as small as possible are, as I said earlier, quite valid and sensible in standalone programming, where no one will ever have to maintain your code...including you, ten years later. Unfortunately, even you won't necessarily remember what some code was supposed to do after that length of time, and the more "optimized" it is, the more difficult it is to read, to the point where depending on the size of the code block you are examining, it may take many hours to figure out what you meant back then. I know you think this is an extreme example, but it is an example I pull from personal experience: code I wrote in my first programming job was code I was still maintaining as a part-time consultant two full-time jobs later, then again when my original boss founded an Internet start-up - and some of that highly efficient code I wrote in 1990 (necessary for multi-megabyte programs being loaded a chunk at a time as overlays in old MSDOS, well before OS/2 and Windows brought virtual memory to the PC-compatible world) was just plain obscure when I had to modify it to sit in a COM object in 2000 (if you think Y2K was a problem, understand how much trouble you can get into when code is written with explicit assumptions of 16-bit integers when it gets moved to a 32-bit integer environment). You may not realize it, but function pointers have been part of C since its inception - it was one of the most fascinating aspects of the language for many of us, and I used them extensively. In fact, this language feature allowed overlays to be built in a language other than assembly language for the first time, one (carefully!!) loaded the code from the binary executable, cast a function pointer to it, then executed it. Templates were described in the original version of the C++ Annotated Reference, but didn't appear in DOS/Windows compilers until, I think, 1992, but I remember writing some pretty frightening code to achieve the same effect (historical note for you: the first C++ compilers weren't compilers, they were preprocessors similar to the one that provides #include and #ifdef, and its output was C code). In order to move from being a good programmer i
-
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