• Create Account

## Your one stop shop for the cause of all coding horrors

38 replies to this topic

### #1Tutorial Doctor  Members

Posted 27 February 2014 - 09:14 PM

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.

They call me the Tutorial Doctor.

### #2C0lumbo  Members

Posted 27 February 2014 - 11:55 PM

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"

### #3Vortez  Members

Posted 27 February 2014 - 11:59 PM

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

ex: if(5 == count)

### #4BGB  Members

Posted 28 February 2014 - 01:03 AM

"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, 28 February 2014 - 01:05 AM.

### #5Tutorial Doctor  Members

Posted 28 February 2014 - 12:52 PM

I have to admit, the Egyptian brackets do annoy me. But then, lower-cased first letters of functions names annoyed me, but now I prefer it that way. So did underscores in variable names.

They call me the Tutorial Doctor.

### #6Zaoshi Kaba  Members

Posted 28 February 2014 - 01:07 PM

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.

### #7Tutorial Doctor  Members

Posted 28 February 2014 - 01:17 PM

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, 28 February 2014 - 01:17 PM.

They call me the Tutorial Doctor.

### #8Zaoshi Kaba  Members

Posted 28 February 2014 - 01:55 PM

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!).

### #9Vortez  Members

Posted 01 March 2014 - 01:04 AM

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: ...
}
}


### #10Dragonsoulj  Members

Posted 01 March 2014 - 01:30 AM

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 "==").

### #11Vortez  Members

Posted 01 March 2014 - 01:37 AM

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, 01 March 2014 - 02:06 AM.

Posted 01 March 2014 - 03:04 AM

is ok, e.g. sscanf

"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley

### #13LJ_1102  Members

Posted 01 March 2014 - 07:17 AM

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, 01 March 2014 - 08:38 PM.

Jan F. Scheurer - CEO @ Xe-Development

### #14Olof Hedman  Members

Posted 01 March 2014 - 07:33 AM

POPULAR

if the assigned value is truthy

That was a nice synonym for "non-zero"

### #15Juliean  GDNet+

Posted 01 March 2014 - 09:40 AM

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, 01 March 2014 - 09:43 AM.

### #16tanzanite7  Members

Posted 01 March 2014 - 10:54 AM

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

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, 01 March 2014 - 10:56 AM.

### #17tanzanite7  Members

Posted 01 March 2014 - 12:12 PM

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.

### #18Dragonsoulj  Members

Posted 01 March 2014 - 01:00 PM

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. ;)

### #19frob  Moderators

Posted 01 March 2014 - 01:31 PM

POPULAR

A few of those are telling.

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

The invalid automatic functions are correct, these are not things the compiler can automatically generate. You are able to create them through a side channel with static initializers or casting, but it isn't a great situation. I'd consider providing the functions.

4100 is a fun one that requires an understanding of the language history. Back in the 1970's before any standardization and C++ was a C variant, developers could use implicit variables. Everything was pushed on the stack and formal parameters (indeed, function prototypes entirely) were not required. It was a common practice to see a function declaration or definition like: foo( param1, param2, param3 ) Note the lack of types and lack of return value, all of them were 'int'. As the language developed, eventually 1985 came around and C++ was released as C++ rather than the AT&T lab's C variant (every lab had their own compiler variant, it was normal back then). The language had completely reversed the situation from 15 years earlier, mandating that the type of all parameters be provided in advance but the names were unnecessary, like: int foo( int, int, int ) Groups went back and forth on the requirements before the c++ language was standardized in 1999. Several compilers, such as Microsoft's, follow the pre-standard pattern that was common over a decade ago where named parameters needed to use the same name and named parameters (and variables) needed to be used or face a warning. The warning is there for historical reasons and some people find it valuable as a diagnostic tool.

The 4310 case is VERY valid in this case. int16(0x8000) is an overflow, since the largest number allowed in int16 is 0x7fff since it is signed.

Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I occasionally write about assorted stuff.

### #20Olof Hedman  Members

Posted 02 March 2014 - 03:39 AM

#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?