Problems in naming variables.

[roberts]

Ok, this is genuine.

I don't like to do lengthy typing, so I tend to go with shot monikers for variable names: boundingbox is bb, vector is v, etc, etc, etc;

Well, my current project is a two parter. The first part scans a 3D geometry and computes the volume. It does this by placing a spanner at an x,y coordinate in 3D space and then does parametric hits against a plane, then tests to see if that hit occurs within the triangle that defines the boundaries of the geometry. I call this a span hit. The spanner is defined by four points that make up a 2D geometry of a current resolution of 0.001 (essentially, this is a millimeter by context). This part links in with the paragraph above when you see the quoted post and I hope it doesn't offend anyone.

The second part is still waiting for me to work on it, but that is neither her nor there.

Anyway, I opened up my project to begin working on an idea and I noticed this in my code:

	// test for hit on the plane
	for( int i = 0; i < 4; i++ )
	{
		sh[i].t = 
	}

and I started to wonder why is there obscenities in my code. I'm going to have to rethink my naming system.

Have any of you similar stories to share about how your coding style made you wonder what you're thinking?

[LB]

	// test for hit on the plane
	for( int oo = 0; oo < 4; ++oo )
	{
		sh[oo].t = 
	}

shoot, and hit!

[Albatross]

I have a lot of fun with variable naming. Here are a few examples from the code of my synthesizer:

for (size_t ic = 0; ic < channelcount; ++ic) { //Loop per internal channel.
                if (comps->gener[ic] != NULL) {

QPushButton* affectedbutt; //Shh...

for (size_t ator = 0; ator < channelcount; ++ator) {
            comps->gener[ator]->noteOn(halfsteps, amp);

std::mutex mutt;

-Albatross

[chrisname]

I don't have any :( Curse my good habits!
I only use single-letter identifiers when it's
a) a loop index (like i, j or k)
b) a mathematical equation.

Albatross wrote:

affectedbutt

Lol.

[Moschops]

I use int eger; and long johnSilver; when I can. They generally get pushed back in code reviews :(

I have yet to manage to justify struct byLightning successfully.

[hanst99]

The... hey, I'm trying so hard to come up with decent names and you guys...

[LB]

I spent literally two hours trying to understand why my friend thought this was funny:
char izard;
I was all like, "What is a care izzard?" And after two long hours, I realized he thought that char was pronounced like charred wood. Thus I responded with char actor;

[chrisname]

Actually, I do have one. In C code, where there are no exceptions, I will sometimes use goto as a way to exit a function and perform clean-up when an error occurs. Usually I try to give the goto label a humorous name.

Something like this (this isn't a real example, I couldn't find any, but I have done it before):

int OpenThreeFilesAndDoNothingForNoReason(const char* path1, const char* path2, const char* path3)
{
        FILE* stream1;
        FILE* stream2;
        FILE* stream3;

        if (!(stream1 = fopen(path1, "r")))
                goto audi5000;
        if (!(stream2 = fopen(path2, "r")))
                goto audi5000;
        if (!(stream3 = fopen(path3, "r")))
                goto audi5000;
        return 0;
audi5000:
        if (stream1) fclose(stream1);
        if (stream2) fclose(stream2);
        if (stream3) fclose(stream3);
        return -1;
}

Normally I wouldn't put a whole if statement and its body on a single line like that but I did this time. Deal with it.

[LB]

I think all single-statement ifs should be single line to make it more obvious that they are SINGLE STATEMENT. So, I actually like it ;)

[Athar]

I think all single-statement ifs should be single line to make it more obvious that they are SINGLE STATEMENT.

Amen to that. Although my motive is rather conserving space and improved readability.

[hanst99]

Eh, I'm the kind of guy who always puts single statements into brace-enclosed indented blocks, just because I don't wanna have to remember two different ways of writing if (..) ... statements.

[LB]

I just use whichever increases code readability the most.

[chrisname]

I think the way hanst99 does it is the best, because it avoids things like this:

if (expression)
        statement1;
        statement2; // Executed regardless of expression 

[LB]

Use Python >_>

[ascii]

Ruby ^^

[Cheraphy]

Perl

[Disch]

because it avoids things like this:

Everyone talks about that like it's some kind of major problem, and I'm forced to follow that rule at my job... but honestly, I've never experienced it even once in my life.

I blame the problem on several things.

1) Some people use stupid brace styles:

if(foo){  // stupid, not immediately obvious that there's a brace here
    bar(); 
}

if(foo)
{  // smarter, immediately obvious there's a brace
    bar();

2) People don't read the code.


3) People use stupid IDEs that don't know how to auto indent. Good IDEs are surprisingly reliable for this kind of thing.

if(f....
    bar();
    // <- if IDE indents here, you're OK

//...
if(f....
    bar();
// <- if IDE indents here, you're not OK) 

[Cheraphy]

I use the curly brace style because I think it looks cleaner.. Then again I have yet to work on code that has a remote chance of being worked on by anyone else.

[Athar]

@Disch
About 3), surely you mean it the other way round?
It wouldn't make sense for an editor to indent the next line.

[LB]

@Disch I agree with Arthar...?