Silly Programming Things You've Come Across
» >
» Goto page 1, 2, 3, 4, 5, 6  Next
» View previous topic :: View next topic  
So sometimes when reading through code, you'll find something just off. I'm not talking about formatting things, because that's all just preference. I'm talking about just weird things.
Here are some examples that I've seen:

Code:
if (boolean)
{
}
else
{
...
}

The comment said "if boolean, than do nothing"... Why not just do:

Code:
if (!boolean)
{
...
}


There was also:

Code:
try {
...
} catch (Exception e) {
throw e;
}


We also saw a bunch of public static const ints, when they could just be in an enum.

And there's this pattern which is just dumb:

Code:
function() {
retval = 0;
try {
retval = function2();
catch { }
return retval;
}


There was also:

Code:
if (false && something_else) {...}


And finally:

Code:
if (!Page.IsPostBack)
{
bindDataGrid(true);
}
else
{
bindDataGrid(false);
}
Shaun
Some of those are pretty horrible. I bet this one, though:
Code:
if (false && something_else) {...}
might just be a technique to force the block not to execute, probably a modification to "comment it out" in a way. I do something similar with code I don't want to be in my z80 ASM programs anymore but want to keep in the source until I'm sure I won't need to refer to it:


Code:
#ifdef false
[lots and lots of code]
#endif
Of course, I need to make sure I never #define false. Very Happy
Right, and I get that, but it's still awkward and should just be commented out instead. Especially when you're in an IDE that let's you easily comment out multiple lines of code.

I suppose that this could fall into the "formatting choice" category.
Shaun
merthsoft wrote:
Right, and I get that, but it's still awkward and should just be commented out instead. Especially when you're in an IDE that let's you easily comment out multiple lines of code.

I suppose that this could fall into the "formatting choice" category.
Oh definitely, no argument here. How about trying to read or modify code from someone that uses a different indentation or whitespace style from you? I usually use a 4-space tab (made of a tab, not spaces), I put curly braces on the line with their associated structure, not their own line, and I separate arithmetic operators from their operands with a space on either side. It drives me nuts trying to work with code, for example, that has two spaces as the tab.
KermMartian wrote:
It drives me nuts trying to work with code, for example, that has two spaces as the tab.

Therein lies the problem. If people used tabs to indent code, others could set them to display at different widths according to their personal preference. This becomes even more chaotic when people mix spaces and tabs for indentation in the same file.

Of course, you can't neatly align with tabs (due to their variable width). I follow the rule that you indent to the current block level with tabs, then align (if required) with spaces.

Of course, a decent IDE will be able to reformat code to your personal preferences (Visual Studio does, at any rate). This can become a problem if more than one person is working on a project, though (it's rather silly to check in formatting changes), so the important thing is consistency. I prefer braces to be on the same line as the associated statement, but don't have any problem reading it the other way.
Sure, I can read it fine either way, but if I then have to add to the code, I'll start automatically typing in my own style, and it takes that extra bit of thinking to follow the other person's style. Smile
I'm pretty anal about those things tbh. If I'm adding code I'll find myself going through the entire source (if it's not tooo long) and replacing all the indent-spaces with tabs, moving the braces to the same line, etc... Laughing
merthsoft wrote:
We also saw a bunch of public static const ints, when they could just be in an enum.


Depending on the language, no they couldn't. Depending on how the values are used, no they couldn't.

In Java, for example, enums are incredibly stupid. In C#, you *could* use an enum instead of public static const ints, unless you actually need the value as an int, and then you are forced to cast it. It works, but its ugly. You also lose strong typing if you do that.

Quote:
And there's this pattern which is just dumb:

Code:
function() {
retval = 0;
try {
retval = function2();
catch { }
return retval;
}


Not really. Its a style choice. Either they can do that, or they can have two return statements. I know some people (very smart and knowledgeable people) who would argue that having two return statements for that is "just dumb".

Quote:
And finally:

Code:
if (!Page.IsPostBack)
{
bindDataGrid(true);
}
else
{
bindDataGrid(false);
}


Also not necessarily dumb. Elegant? No. An example of what not to do? Absolutely not. This is also more of a style choice, as it minimizes the amount of code on a single line.
There are only two kinds of programming languages: those people always bitch about and those nobody uses. (Bjarne Stroustrup)
I don't think that the easier readability of the last one in terms of seeing what it's doing is worth turning what should be a single line with two nested statements into an eight-line monstrosity.
KermMartian wrote:
I don't think that the easier readability of the last one in terms of seeing what it's doing is worth turning what should be a single line with two nested statements into an eight-line monstrosity.


I agree, but you are also the guy who said 2 or 3 nested ternaries was OK - so you certainly don't have a good understanding of readability Razz

My point was it's far from a WTF
There are only two kinds of programming languages: those people always bitch about and those nobody uses. (Bjarne Stroustrup)
You have a problem with even two measly nested ternaries? I know that I write longer and more packed lines of code than many, but surely you can live with two conditionals and three statements on one line. Razz
Quote:
Of course, you can't neatly align with tabs (due to their variable width). I follow the rule that you indent to the current block level with tabs, then align (if required) with spaces.

Agreed.

Quote:
Depending on the language, no they couldn't. Depending on how the values are used, no they couldn't.

I figured this would be clear on its own, but when I say they could easily have it in an enum, I mean it. With the way it's being used, it should be in an enum.

Quote:
I know some people (very smart and knowledgeable people) who would argue that having two return statements for that is "just dumb".

I suppose this could be counted as stylistic. Maybe. But that way is harder to read, and takes a little bit more thought. And I hate thinking. I want to just see the code and for it to make sense. The compiler will just optimize it down anyways.

Quote:
This is also more of a style choice, as it minimizes the amount of code on a single line.

Yeah. I'll concede that this is style. It still irks me, though. It could just be one very understandable line, instead of 8 very understandable lines.

Quote:
you are also the guy who said 2 or 3 nested ternaries was OK

I'm with Kerm, there. Two or three nested ternaries are OK, assuming you're used to the pattern. When I was first learning, I remember being pretty confused by this. This is probably also a stylistic thing.

Meanwhile,

Code:
if (boolean)
{
}
else
{
...
}

Is still dumb.

Does anyone else have any examples? I'm sure other people have come across things that just jump out at you and make you go "wtf?". And since I broke my own rule, let's get some stylistic things too, then. Like K&R function definitions:

Code:
void
capture_callback(buffer, packet_header, data)
u_char *buffer, const struct pcap_pkthdr *packet_header,
u_char *data;
Shaun
merthsoft wrote:
Does anyone else have any examples? I'm sure other people have come across things that just jump out at you and make you go "wtf?". And since I broke my own rule, let's get some stylistic things too, then. Like K&R function definitions:

Code:
void
capture_callback(buffer, packet_header, data)
u_char *buffer, const struct pcap_pkthdr *packet_header,
u_char *data;
Ironically enough, although I understand that fine, GCC seems to have forgotten how to deal with it unless I give it an extra flag. I just two days ago converted many hundreds of lines of codes containing dozens of functions declared in K&R style into the current standard style.

This is z80 ASM, not C, and I bet it's a stylistic thing, but Iambian (who is an excellent human being and coder, and to whom I intend no disrespect whatsoever) has a propensity for both using a single space to tab his code, and does short jumps via the jr $+n or jr $-n syntax. I'm always worried I'm going to insert or remove opcodes and forget to update the value of n in those statements. For example:


Code:
 ld a,(xlib04)
 dec a
 jr nz,$+5
 ld hl,768
 push hl
  ld a,PictObj
  bcall($4E70)  ;CreateVar
  pop bc
 inc de


Another thing that bothers me is people who liberally sprinkle magic numbers throughout their C code with no attempt to make them static ints or even #defines.
KermMartian wrote:
Ironically enough, although I understand that fine, GCC seems to have forgotten how to deal with it unless I give it an extra flag. I just two days ago converted many hundreds of lines of codes containing dozens of functions declared in K&R style into the current standard style.

That's weird. I figured GCC would just do it. It's a stupid style, anyways.

KermMartian wrote:
This is z80 ASM, not C, and I bet it's a stylistic thing, but Iambian (who is an excellent human being and coder, and to whom I intend no disrespect whatsoever) has a propensity for both using a single space to tab his code, and does short jumps via the jr $+n or jr $-n syntax. I'm always worried I'm going to insert or remove opcodes and forget to update the value of n in those statements.

Oooh, one space. That's bizarre. As for short jumps, those always seem like a bad idea to me, for the reason you said. Just add a label, even if it's not descriptive, at least it's something.

KermMartian wrote:
Another thing that bothers me is people who liberally sprinkle magic numbers throughout their C code with no attempt to make them static ints or even #defines.

I hate magic numbers. Sometimes I'm too lazy to throw in a #define, but I'll at least comment it.
Shaun
KermMartian wrote:


This is z80 ASM, not C, and I bet it's a stylistic thing, but Iambian (who is an excellent human being and coder, and to whom I intend no disrespect whatsoever) has a propensity for both using a single space to tab his code, and does short jumps via the jr $+n or jr $-n syntax. I'm always worried I'm going to insert or remove opcodes and forget to update the value of n in those statements.


I also hate it when I'm reading some complicated piece of source that uses those $+n statements. Usually I convert them to labels by hand. Much easier to understand Smile
Projects:

Random Stuff.

Speaking of labels, I bet something that other coders would criticize me for is excessively-long labels (see also this thread: http://www.cemetech.net/forum/viewtopic.php?t=4343). Some of my recent gems:


Code:
dbfGUIMouse_StringReturnLenLoop_Single
dbfGUIMouse_StringReturnStoreLoop_Single
dbfGUIMouse_StringSize_NoDelimitYet
dbfPushGUIStack_EntryTable
dbfStringWidthLoopInner
KermMartian wrote:
Speaking of labels, I bet something that other coders would criticize me for is excessively-long labels (see also this thread: http://www.cemetech.net/forum/viewtopic.php?t=4343). Some of my recent gems:


Code:
dbfGUIMouse_StringReturnLenLoop_Single
dbfGUIMouse_StringReturnStoreLoop_Single
dbfGUIMouse_StringSize_NoDelimitYet
dbfPushGUIStack_EntryTable
dbfStringWidthLoopInner


Personally, I'm alright with long label or variable names.
dbfGUIMouse_StringReturnLenLoop_Single
is a lot easier for me to parse (and therefore remember) than, say:
dbfGM_StrRtnLnLoop_Sngl

Especially when there is inconsistent use of vowels and such, longer usually means clearer. There is, of course, such a thing as too long (and too clear for that matter), but I think those are fine. Personally.

Oh, and I've got something else. It's not really a programming thing, but we got this compilation error:


Code:
[josh@jlrbv Project Euler]$ g++ -o problem211 problem211.cpp
problem211.cpp:7: error: ‘long long long’ is too long for GCC


And it made us laugh.
Shaun
I try to do something intelligent, like SectionName_SubLabel_SubSubLabel for the sake of consistency. What do you do for casing?
Quote:

Code:
function() {
retval = 0;
try {
retval = function2();
catch { }
return retval;
}


Most people will tell you that a single point of return is good style.

Kllrnohj wrote:
KermMartian wrote:
I don't think that the easier readability of the last one in terms of seeing what it's doing is worth turning what should be a single line with two nested statements into an eight-line monstrosity.


I agree, but you are also the guy who said 2 or 3 nested ternaries was OK - so you certainly don't have a good understanding of readability Razz

2 or 3 (or 4 Very Happy ) nested ternaries are fine if you format them properly. I would rather write terse code and spend a little time formatting and commenting it than I would write unnecessary code to make it more readable. Also, that particular example adds an unnecessary branch.


Anyway, this topic would be incomplete without a link to http://thedailywtf.com/
<- Please Support on Lego Ideas
Ah yes, I had forgotten about that, elfprince. Excellent call. Smile
And I agree that it's better to have a single point or return than multiple, especially if you eventually change the type or variable or structure that your function returns.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Silly Programming Things You've Come Across
» Goto page 1, 2, 3, 4, 5, 6  Next
» View previous topic :: View next topic  
Page 1 of 6
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement