• Create Account

36 replies to this topic

### #21ZebraQuake  Members

131
Like
0Likes
Like

Posted 15 April 2013 - 03:27 PM

Even "p" as the position of a particle is ambiguous - it could easily be momentum (which is denoted as "p"). I've always despised single-letter variables (Volume? Velocity? Voltage? Acceleration? Amperes? Area?) even when dealing with mathematics. Walking into programming where it's expected that variable names be descriptive with such behavior is, in my opinion, inexcusable. I mean, "vel" is already a massive improvement over "v" (likewise with "pos" and such)

### #22Azaral  Members

467
Like
1Likes
Like

Posted 15 April 2013 - 10:18 PM

Yes, I hate trying to read code where they use short hand variable names.

The human brain is wired to instantly recognize words it knows. You read number all over the place. When you see number even if it is not in the correct order, you will be able to recognize it as such.

Writing out words instead of short handing them makes the code SOOO much easier to read.

"Aoccdrnig to a rscheearch at Cmabrigde Uinervtisy, it deosn't mttaer in waht oredr the ltteers in a wrod are, the olny iprmoatnt tihng is taht the frist and lsat ltteers be at the rghit pclae. The rset can be a toatl mses and you can sitll raed it wouthit porbelm. Tihs is bcuseae the huamn mnid deos not raed ervey lteter by istlef, but the wrod as a wlohe."

That right there should be evidence enough for people to use FULL AND MEANING FULL words for their code. Is it really that much more effort to type a few extra letters.

### #23Bacterius  Members

13100
Like
1Likes
Like

Posted 15 April 2013 - 10:55 PM

That right there should be evidence enough for people to use FULL AND MEANING FULL words for their code. Is it really that much more effort to type a few extra letters.

Better yet - now we can randomize variable names without impeding code readability, as lnog as the frsit and lsat cahracetrs are in the rghit palce

That said there is an anti-argument to this - ridiculously long variable and function names lead to extremely long code lines (think business java code with getCustomerFormAndIDFileSecureTransactionDBConcurrent() methods) which are difficult to read, not to mention print. So a balance needs to be achieved somehow.

Edited by Bacterius, 15 April 2013 - 10:56 PM.

“If I understand the standard right it is legal and safe to do this but the resulting value could be anything.”

### #24Azaral  Members

467
Like
0Likes
Like

Posted 15 April 2013 - 11:07 PM

That right there should be evidence enough for people to use FULL AND MEANING FULL words for their code. Is it really that much more effort to type a few extra letters.

Better yet - now we can randomize variable names without impeding code readability, as lnog as the frsit and lsat cahracetrs are in the rghit palce

That said there is an anti-argument to this - ridiculously long variable and function names lead to extremely long code lines (think business java code with getCustomerFormAndIDFileSecureTransactionDBConcurrent() methods) which are difficult to read, not to mention print. So a balance needs to be achieved somehow.

Heh. They COULD be random, if you're happy with your code not compiling

And yeah, obviously if its TOO long then you've got a problem too.

### #25Hodgman  Moderators

49385
Like
11Likes
Like

Posted 16 April 2013 - 03:13 AM

POPULAR

The right balance depends on the scope of the variable. If you've got a 3-line loop body, with Vec3 p = blah.position; as the first line, then there's no problem, as further explanation about what 'p' means appears in the same context.
If someone has a member variable named 'p', then the class better be pretty damn simple/small/self-explanatory.
If someone has a global variable named 'p', they can GTFO ;-)

The larger the scope, the longer the appropriate name length.

### #26Azaral  Members

467
Like
1Likes
Like

Posted 16 April 2013 - 06:41 AM

The right balance depends on the scope of the variable. If you've got a 3-line loop body, with Vec3 p = blah.position; as the first line, then there's no problem, as further explanation about what 'p' means appears in the same context.
If someone has a member variable named 'p', then the class better be pretty damn simple/small/self-explanatory.
If someone has a global variable named 'p', they can GTFO ;-)

The larger the scope, the longer the appropriate name length.

Yeah, that sounds like a reasonable line of reasoning.

### #27Khatharr  Members

7655
Like
2Likes
Like

Posted 16 April 2013 - 03:39 PM

The right balance depends on the scope of the variable. If you've got a 3-line loop body, with Vec3 p = blah.position; as the first line, then there's no problem, as further explanation about what 'p' means appears in the same context.
If someone has a member variable named 'p', then the class better be pretty damn simple/small/self-explanatory.
If someone has a global variable named 'p', they can GTFO ;-)

The larger the scope, the longer the appropriate name length.

Yeah, that sounds like a reasonable line of reasoning.

I think it's reasonably reasonable for you to say that his reasoning is reasonable.

void hurrrrrrrr() {__asm sub [ebp+4],5;}

There are ten kinds of people in this world: those who understand binary and those who don't.

### #28Azaral  Members

467
Like
3Likes
Like

Posted 16 April 2013 - 04:20 PM

The right balance depends on the scope of the variable. If you've got a 3-line loop body, with Vec3 p = blah.position; as the first line, then there's no problem, as further explanation about what 'p' means appears in the same context.
If someone has a member variable named 'p', then the class better be pretty damn simple/small/self-explanatory.
If someone has a global variable named 'p', they can GTFO ;-)

The larger the scope, the longer the appropriate name length.

Yeah, that sounds like a reasonable line of reasoning.

I think it's reasonably reasonable for you to say that his reasoning is reasonable.

How reasonable of you!

### #29Sik_the_hedgehog  Members

2948
Like
0Likes
Like

Posted 16 April 2013 - 08:00 PM

The reasonable amount of reasonably reasonable posts in this reasonable thread is reasonably reasonable.

...I dare you to read that sped up =P

Don't pay much attention to "the hedgehog" in my nick, it's just because "Sik" was already taken =/ By the way, Sik is pronounced like seek, not like sick.

1343
Like
0Likes
Like

Posted 18 April 2013 - 09:21 PM

I think that everyone is being too reasona...oh what the crap, it isn't worth it.  I'm screwing it up.  This being reasonable stuff is becoming unreasonable!

### #31AfroFire  Members

424
Like
4Likes
Like

Posted 27 June 2013 - 12:33 AM

I came to provide some reason to this thread, but I see it has enough already.

Note: There is some serious physics simulation software (see GADGET-2) that has some horribly named variables. It's very readable to a physicist, but makes a CS major bawl. Different area, different rules.

To state the obvious: There just isn't a 'global' set of rules on how we should name variables, even something like 'readability' and understandability differs from group to group. Physics equations fall apart when you start naming things "velocity_x" and then using it all over the place and being able to find an error in the code gets worse the less it looks like an equation and the more like code it looks. Tracking down these kinds of errors is a bitch.

But as someone reasonably stated: The wider the scope, the longer the name should be. Or, fuck, leave a comment that says "Look up the equation in such and such's paper, or book on page x"

AfroFire | Brin"The only thing that interferes with my learning is my education."-Albert Einstein

### #32wodinoneeye  Members

1669
Like
0Likes
Like

Posted 13 July 2013 - 03:58 PM

a random variable doing...nothing on the 4th line?

Well to be fair I have hand-picked the worst from this code, and this is just a beginning of the method.

That is clear and concise compared to alot/much of code Ive worked on in my professional career

Add some blanks spacings and carriage returns and some alignment/indentation  of common statement elements and tnat would be clearer than most of the Microsoft code Ive seen

Ive seen alot of code in 'books' that are the opposite spaced out rediculously

Just do what I do and take a library like that and put it through a 'pretty' printer program I wrote that reorgamizes the code to my own style (or do it by hand - seriously it wont take that long and you would get a readthrough of the code giving you some understanding of what the lib actually does)

---

as for variable names most of those usages are very tight minimal in their function  (let hear after you start having 8 way nested loops)

Now if they start having object class  with dozens of attributes or more obscure usage of the variables (besides initialization loops)  then longer names are warranted.

Edited by wodinoneeye, 13 July 2013 - 04:02 PM.

--------------------------------------------Ratings are Opinion, not Fact

### #33Sooshi  Members

149
Like
0Likes
Like

Posted 19 July 2013 - 06:38 AM

I wouldn't say that using p as a name for verticle position variable is a coding horror, especially if it is some particle class with position (p), velocity (v) and acceleration (a), where the meaning is quite obvious. I personaly would use at least pos, vel, acc, but probably not the full text. Acceleration is so long to write...

Yea I know what you mean. I usually just write out the full name for my variables, with comments on what each of them are meant to be used for. Takes longer to type but helps me out in the end when coming back to my code to get myself up to speed.

### #34wodinoneeye  Members

1669
Like
0Likes
Like

Posted 19 August 2013 - 07:29 AM

int      l, dijk, dijkl, dijkr, ima, qi, qj, qidiv, qjdiv, fi, fj, fijk2;
double   disx, disy, switchx, switchy, switchx2 ,disxl, disxr, disx2, disxr2;

dijk    = di + nx * (dj + oy * dk);
ima     = step_div(dk - ez, nz);
qj      = dj + step_int(-ima * byz * ysp);
qjdiv   = step_div(qj - ey, ny);
qi      = di + step_int((-ima * bxz - qjdiv * bxy) * xsp);
qidiv   = step_div(qi, nx);
fi      = qi - qidiv * nx;
fj      = qj - qjdiv * ny,

fijk    = fi + nx * (fj + oy * (dk - ima * nz));

disy    = ima * byz + qjdiv * by;
switchy = (dj - ey) * boxy - ima * byz - qjdiv * by;

disx    = ima * bxz + qjdiv * bxy + qidiv * bx;
switchx = di * boxx - ima * bxz - qjdiv * bxy - qidiv * bx;

//This is what you would largely see after my usual treatment
//(and I likely would add some extra parens around the multiplies
//to emphasise the ordering

Does look a bit clearer after youve isolated the variable definitions (that partial list) from the calculation statements and added spacers to make the functions and variables more distinct.

Imagine how much more fun the above code would be with ALL  8+ char variable names  (and those function name would have to be expanded too --- wouldnt they ?....)

Short variable names dont bother me so much - but if there is anything weird/unusual  being done I will heavily comment to make clear some atypical code.

Edited by wodinoneeye, 19 August 2013 - 07:40 AM.

--------------------------------------------Ratings are Opinion, not Fact

### #35rnlf  Members

1775
Like
0Likes
Like

Posted 20 August 2013 - 01:47 AM

Looks to me like an implementation of some paper. If you want your code to be easily understandable for someone who knows the paper, I guess this is not that bad style. One might want to add an underscore to express subscripts in TeX-style like in "d_ijk". Sure, you don't easily understand the code without knowing the source of the algorithm, but if you name your stuff to match names from the paper you're implementing, people will find it easier to verify your implementation against the paper...

If this code was written without a scientific paper as its background, well... that'd be bad ;-)

### #36iAmCodeMonkey  Members

215
Like
2Likes
Like

Posted 06 November 2013 - 09:45 PM

int l,dijk=di+nx*(dj+oy*dk),dijkl,dijkr,ima=step_div(dk-ez,nz);
int qj=dj+step_int(-ima*byz*ysp),qjdiv=step_div(qj-ey,ny);
int qi=di+step_int((-ima*bxz-qjdiv*bxy)*xsp),qidiv=step_div(qi,nx);
int fi=qi-qidiv*nx,fj=qj-qjdiv*ny,fijk=fi+nx*(fj+oy*(dk-ima*nz)),fijk2;
double disy=ima*byz+qjdiv*by,switchy=(dj-ey)*boxy-ima*byz-qjdiv*by;
double disx=ima*bxz+qjdiv*bxy+qidiv*bx,switchx=di*boxx-ima*bxz-qjdiv*bxy-qidiv*bx;
double switchx2,disxl,disxr,disx2,disxr2;


WTF?!

I have never seen something so bad in my life when it came to horrid variable names and completely unreadable code. Seriously.

### #37slicer4ever  GDNet+

6352
Like
1Likes
Like

Posted 07 November 2013 - 03:14 PM

int l,dijk=di+nx*(dj+oy*dk),dijkl,dijkr,ima=step_div(dk-ez,nz);
int qj=dj+step_int(-ima*byz*ysp),qjdiv=step_div(qj-ey,ny);
int qi=di+step_int((-ima*bxz-qjdiv*bxy)*xsp),qidiv=step_div(qi,nx);
int fi=qi-qidiv*nx,fj=qj-qjdiv*ny,fijk=fi+nx*(fj+oy*(dk-ima*nz)),fijk2;
double disy=ima*byz+qjdiv*by,switchy=(dj-ey)*boxy-ima*byz-qjdiv*by;
double disx=ima*bxz+qjdiv*bxy+qidiv*bx,switchx=di*boxx-ima*bxz-qjdiv*bxy-qidiv*bx;
double switchx2,disxl,disxr,disx2,disxr2;

WTF?!

I have never seen something so bad in my life when it came to horrid variable names and completely unreadable code. Seriously.

Theirs the thread that spawned the great gd.net horror experiment, suggest you check it out if you wanna see something truly horrible.
Check out https://www.facebook.com/LiquidGames for some great games made by me on the Playstation Mobile market.