• Advertisement
Sign in to follow this  

Your one stop shop for the cause of all coding horrors

This topic is 1400 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

You gotta see this article:

 

http://blog.codinghorror.com/new-programming-jargon/

 

The keyword I was looking for in my shorthand post was "refuctoring". 

 

It could be that I am just a "Jimmy" 

 

I kinda like the "Smurf Naming Convention" though. haha. 

Share this post


Link to post
Share on other sites
Advertisement

My personal project right now is a world conquest game that has various source files for rendering the globe. The internal name of the project (i.e. the one I use in code, not the one it will release under) is Globo.

 

I think of that Smurf Naming thing every time I type: #include "Globe/Globo_Globe.h"

Share this post


Link to post
Share on other sites

"Heisenbug"

 

yeah, those are annoying...

 

like, bug which is annoyingly hard to recreate and occurs rarely, may appear only when not run in a debugger, or when the code is stopped/single-stepped there is no evidence of the bug's existence... (ex: program runs with a bug, set a break-point, single-step, and everything works as intended...).

 

 

may sometimes be due to "spooky action at a distance", like (off somewhere in some distant part of the program) instead of writing "foo[x*y+z]=...;" one wrote "foo[x*y*z]=...;" which may otherwise go largely unnoticed if it fails to land on an unused memory address (may be very common for programs where most of the address space is in-use).

 

may be also be called "dude, where's my RAM?" if it also results in an intermittent memory leak.

Edited by BGB

Share this post


Link to post
Share on other sites


Egyptian brackets do annoy me

I prefer Egyptian brackets because it eats less lines. Indents give enough information what is inside which block so I don't need brackets to tell me same thing.

Share this post


Link to post
Share on other sites
function EgyptianizeTheBracket(){
    looks missing;
}

function UnEgyptianizeTheBracket()
     { for short lines;}

function UnEgyptianizeTheBracket()
     {
     for longer lines;
     }

Good point Zaoshi. I just think that having them on the next line shows the start and end of the code inside the function. Along with indentation it just looks neater. 

Edited by Tutorial Doctor

Share this post


Link to post
Share on other sites

I've been using Egyptian brackets for a long time, so I read indentation, not brackets. When I have to read code based on brackets instead of indents it's too hard for me (luckily VS2013 has autoformatting!).

Share this post


Link to post
Share on other sites

I love egyptian brackets but not everywhere, i think they are most fitted for ifs and while/for loops. Function and switch should use normal brackets style.

void Function()
{
    if(x == 1){

    }

    for(;;){

    }

    switch(x)
    {
    case 0: ...
    }
}

Share this post


Link to post
Share on other sites

Nice article, i personally hate with passion the "Yoda Conditions".

 

ex: if(5 == count)

 

There is a reason for these. They throw errors at compile time if you try assigning improperly (for instance forgetting your second "==").

Share this post


Link to post
Share on other sites

Maybe, but as the article says, it like saying "if blue is the sky" or "if tall is the man", it's just harder to read this way imo. Forgetting a '=' is not an excuse for writing harder to read code imo, since that doesn't happen very often.

 

Beside, i dont know about other compilers, but doesn't visual studio warn us about this kind of error as a warning at compile time?

 

EDIT: Seem like it dosent warn you after all... i was mistaken. That's a weird quirk of the language tho, assigning a value returning true, i never understood why c++ allowed that in the first place.

Edited by Vortez

Share this post


Link to post
Share on other sites

EDIT: Seem like it dosent warn you after all... i was mistaken. That's a weird quirk of the language tho, assigning a value returning true, i never understood why c++ allowed that in the first place.
 

 

This is not a quirk of the language, its only returning true if the assigned value is truthy, this allows for constructs like the following that are allowed in almost all languages i've ever used:

while (mesh = imaginaryMeshStack.pop()) {
// do stuff with "mesh" here
}

EDIT: "returning true" is the wrong wording, "evaluates to true" fits better here.

Edited by LJ_1102

Share this post


Link to post
Share on other sites

EDIT: Seem like it dosent warn you after all... i was mistaken. That's a weird quirk of the language tho, assigning a value returning true, i never understood why c++ allowed that in the first place.

 

It doesn't really return true, it "returns" the result of the assignement.

if(var = 5) // -> if(5) => true

if(var = 0) // -> if(0) => false

It has its uses though

if(auto pMesh = GetMesh(L"Lala") // only enters when pMesh is no nullptr
{
 // DO SOMETHING
}

// pMesh not accessible here
// VS

auto pMesh = GetMesh(L"Lala");
if(pMesh != nullptr)
{
 // DO SOMETHING
}

// pMesh still accessible

EDIT:

 

It does warn you of the opposite, though:

const int constant = 5;
int variable = 0;
variable == constant;
warning C4553: '==': operator has no effect; did you intend '='?
Edited by Juliean

Share this post


Link to post
Share on other sites

EDIT: Seem like it dosent warn you after all... i was mistaken. That's a weird quirk of the language tho, assigning a value returning true, i never understood why c++ allowed that in the first place.

In my experience, at least VC++ versions 2008/2010/2012/2013 will give "warning C4706" - if your warning level is at least /W4. However, some of the warnings are just noise (constant conditional expression). "/w44706" might be more preferable option (sets warning level for C4706 to 4, without affection others).

http://msdn.microsoft.com/en-us/library/thxezb7y%28v=vs.120%29.aspx

Recheck your settings.

 

edit: Forgot to add my 2 cents. I hate "Yoda Conditions" and consider it a strictly bad practice. Just do not do it.

Edited by tanzanite7

Share this post


Link to post
Share on other sites

Actually, since i mentioned the existence of useless/unhelpful/bogus warnings - why not share them. For readers benefit:

 

#pragma warning(disable : 4201) // (BOGUS) nonstandard extension used : nameless struct/union  // C++11 allows it
#pragma warning(disable : 4510) // (BOGUS and USELESS) default constructor could not be generated // generates an incorrect warning with "struct Foo { const int; } snafu[] = {{1}, {2}}; "
#pragma warning(disable : 4610) // (BOGUS and USELESS) struct can never be instantiated - user defined constructor required // this is just wrong (caused by const member variable)
#pragma warning(disable : 4512) // (BOGUS and USELESS) assignment operator could not be generated // it is only a problem when you use it - and it is an error then. What was the point of this warning again?
#pragma warning(disable : 4100) // (UNHELPFUL) unreferenced formal parameter // i prefer to keep the name of the parameter for clarity even if the particular implementation does not use it
#pragma warning(disable : 4127) // (UNHELPFUL) conditional expression is constant // this is actually almost always desired
#pragma warning(disable : 4310) // (UNHELPFUL) cast truncates constant value // BOGUS: int16(0x8000), VALID: int16(100000). However - i have never encountered the later.
 

With thous i have no warnings at all with warning level 4.

Share this post


Link to post
Share on other sites

Maybe, but as the article says, it like saying "if blue is the sky" or "if tall is the man", it's just harder to read this way imo. Forgetting a '=' is not an excuse for writing harder to read code imo, since that doesn't happen very often.

 

Beside, i dont know about other compilers, but doesn't visual studio warn us about this kind of error as a warning at compile time?

 

EDIT: Seem like it dosent warn you after all... i was mistaken. That's a weird quirk of the language tho, assigning a value returning true, i never understood why c++ allowed that in the first place.

 

Depends on how your read it. "if blue matches (is) the color of the sky" or "if tall matches (is) the height description of the man" Gotta name your variables something meaningful. ;)

Share this post


Link to post
Share on other sites


#pragma warning(disable : 4127) // (UNHELPFUL) conditional expression is constant // this is actually almost always desired

 

It is? Isn't the conditional expression rather pointless if it is constant or am I missing something?

Share this post


Link to post
Share on other sites

Gamedev forum software crapped its pants again, so can not use any formatting. Did my best to make it readable.

------------------------

 

frob: "4201 is valid unless you told the compiler to use c++11."

 

VC++ does not have such a specific switch - all that it is capable of supporting is enabled by default. And i use a lot of c++11 features. One might say that vc++ is not really c11 - but that is not an useful distinction as it tries to be everywhere else.

 

frob: "The invalid automatic functions are correct, these are not things the compiler can automatically generate."

 

_Nor does it need to_. The warning is a very low priority bug in the compiler: http://connect.microsoft.com/VisualStudio/feedback/details/488660/improper-issuance-of-c4610

 

Even so, it is still an useless warning as the language does not allow improper use anyway (ie. more than it normally does) - there is nothing worth warning about.

 

And yes, one should generally avoid such structures. Exceptions excepted (funny: commented out the warning to see where i use them => apparently i do not use them at all anymore [except a few of the assignment ones - adding "=delete" assignments]).

 

frob: "4100 is a fun one that requires an understanding of the language history."

 

Interesting. I did not know that backstory. Thanks.

 

frob: "The 4310 case is VERY valid in this case. int16(0x8000) is an overflow"

 

Exactly. Which is why it is tagged "UNHELPFUL" instead of "BOGUS" or "USELESS". Unhelpful is a fairly subjective tag (*).

 

I use, in every language, hex-notation to signify bit-patterns. Ie. "int16(0x8000)" should be interpreted as bit-pattern 0x8000 in int16 storage (_ie. platform dependently interpreted as some 16 bit integer_). Obviously, C does not interpret it that way and never will - not a problem here.

 

The warning is very rare.

 

I have only a few of them from various macro-driven tests. Platform specific integer conversion ... the only place where anyone would write stuff like "int16(0x8000)". Hm, i should move the pragma there and undo it after the test section - much more sane. Thanks.

 

(*) I copy pasted thous few example lines out - leaving out some less likely useful ones (and commented out unused ones) and a few comments. One of them probably bited here. Pragma reminder-comment in split with "//": left of it is about the warning - to the right is for use-case reminders of how one might get the warning etc. So, BOGUS for "int16(0x8000)" does not mean the warning is bogus! - it signifies that it is UNHELPFUL as it is BOGUS for the use-case (the bit pattern fits nicely).

 

Perhaps i should have left out all the UNHELPFUL tagged ones here due of their high subjectivity.

Share this post


Link to post
Share on other sites


Maybe, but as the article says, it like saying "if blue is the sky" or "if tall is the man", it's just harder to read this way imo. Forgetting a '=' is not an excuse for writing harder to read code imo, since that doesn't happen very often.

It happens an awful lot more than you might expect. Defensive coding is important, and it often comes at a perceived cost to readability.

 

I'd honestly be rather alarmed to meet a senior engineer who didn't write their conditions that way, when coding in C++.

Share this post


Link to post
Share on other sites

 


#pragma warning(disable : 4127) // (UNHELPFUL) conditional expression is constant // this is actually almost always desired

 

It is? Isn't the conditional expression rather pointless if it is constant or am I missing something?

 

 

while(RUNNING == gameState)
{
  // Run Game Code
}

Share this post


Link to post
Share on other sites

Oh, missed a post.

 

 


#pragma warning(disable : 4127) // (UNHELPFUL) conditional expression is constant // this is actually almost always desired

 

It is? Isn't the conditional expression rather pointless if it is constant or am I missing something?

 

 

Typical direct example: "while(true) { ... }". But it usually comes indirectly from macros and templates (ie. stuff that is not, in its final, form written by the programmer).

 

Ie. the warning is valid, but unfortunately tends to flag code that is perfectly fine - which is just too annoying of a problem when one treats warnings as errors that could be temporarily ignored. Hence: UNHELPFUL.

Share this post


Link to post
Share on other sites
while(RUNNING == gameState)
{
  // Run Game Code
}

 

That's not a constant conditional expression, unless gameState is const, which I assume it is not...

 


But it usually comes indirectly from macros and templates (ie. stuff that is not, in its final, form written by the programmer).
Ie. the warning is valid, but unfortunately tends to flag code that is perfectly fine - which is just too annoying of a problem when one treats warnings as errors that could be temporarily ignored. Hence: UNHELPFUL.

 

Ah of course, got it.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement