• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Nercury

Academia

36 posts in this topic

Yeah, you need longer variable names. I suggest:

 

alpha instead of a

beta instead of b

pi_thing instead of p (since pi may cause confusion).

0

Share this post


Link to post
Share on other sites


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;

/*
so you have created qj, qi, and more badly named
crap at the top of your function... again.
*/


O man, that's just....I don't even know. is their actually comma separated code in that? and a random variable doing...nothing on the 4th line?
that student needs to get a talking to.

I think with things like visual assist x, and code-completion tabbing. i've pretty much stopped doing this practice(although i never did it very much anyway). I like to use full names for things most of the time, just because of the fact that it looks nicer at the end of the day.

edit: that's actually making me a bit sick looking at it, i'm ganna go lie down for a bit now. Edited by slicer4ever
0

Share this post


Link to post
Share on other sites
int l;

is especially nice, especially if you use a font which makes l and 1 look very similar.

 

EDIT: Obviously it should be called lambda

Edited by Paradigm Shifter
0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

Oh sure it is more compact. And that is NOT a good thing. Of COURSE I can figure out what it all means eventually, I am not THAT stupid. But it is not the point.

I can't and I'm not that stupid (OK, I am, but still). That thing is just plain unreadable, I have an easier time reading blobs from hex editors... I'd kick immediately anybody who came up with code like that. The only place where I'd tolerate something like that is for stuff like 4k demoscene compos or something similar (and where the 4k limit applies on the source code, e.g. javascript demos and such).

 

Also oh god that last link... WHY (?°?°)?? ???

1

Share this post


Link to post
Share on other sites
remap(ai,aj,ak,ci,cj,ck,x,y,z,ijk);
vc.find_voronoi_cell(x,y,z,ci,cj,ck,ijk,w,mrs);
This code has to be generated by a machine. Or he did a search & replace at the very end. No sane human can make sense of this.
2

Share this post


Link to post
Share on other sites


struct Vertex
{
   int index;
   float x;
   float y;
   float z;
   Vertex* next;
};
float getX(Vertex* head, int index)
{
   Vertex* p = head;
   while(p)
   {
      if(p->index == index)
         return p->x;
      p = p->next;
   }
   return 0;
}
float getY(Vertex* head, int index)
{
   Vertex* p = head;
   while(p)
   {
      if(p->index == index)
         return p->y;
      p = p->next;
   }
   return 0;
}
float getZ(Vertex* head, int index)
{
   Vertex* p = head;
   while(p)
   {
      if(p->index == index)
         return p->z;
      p = p->next;
   }
   return 0;
}
struct Face
{
   int index;
   int i0;
   int i1;
   int i2;
   Face* next;
};
int getV0(Face* head, int index)
{
   Face* f = head;
   while(f)
   {
      if(f->index == index)
         return f->i0;
      f = f->next;
   }
   return 0;
}
int getV1(Face* head, int index)
{
   Face* f = head;
   while(f)
   {
      if(f->index == index)
         return f->i1;
      f = f->next;
   }
   return 0;
}
int getV2(Face* head, int index)
{
   Face* f = head;
   while(f)
   {
      if(f->index == index)
         return f->i2;
      f = f->next;
   }
   return 0;
}
void drawMesh(Face* f, Vertex* v, int n)
{
   glBegin(GL_TRIANGLES);
   for(int i=0;i<n;++i)
   {
       glVertex3f(getX(getV0(f,i)), getY(getV0(f,i)), getZ(getV0(f,i)));
       glVertex3f(getX(getV1(f,i)), getY(getV1(f,i)), getZ(getV1(f,i)));
       glVertex3f(getX(getV2(f,i)), getY(getV2(f,i)), getZ(getV2(f,i)));
   }
   glEnd();
}


o god, that's horrid, and so incredibly inefficient, I don't even know.
1

Share this post


Link to post
Share on other sites

o god, that's horrid, and so incredibly inefficient, I don't even know.

It was all like that, but his exam marking was his worst offence. He'd often fail 50% of a year group, and barely pass the rest. All because he had absolutely no clue. If the students had me as a second marker, they were lucky. Some other 2nd markers weren't as diligant though :(
 

Why do you need to name your class fields as c, cc, d, e? What the hell are you trying to obfuscate?

 

Most lecturers are generally pretty level headed, and do try to keep their code clean and readable. The more research based they are however, the more chance there is for strangeness to creep in. Academic research can be quite an isolating experience, so you don't often have people around to bounce ideas off, which does tend to encourage people to slip into some really bizarre habits.

 

There is also a tendancy for some senior academics to stick their name on top any paper from any student they are supervising. This experience can make a junior researcher quite paranoid, and overly protective of their work. Once they've got a Phd, often this paranoia doesn't leave the academic, but simply becomes much more engrained. Maintaining secrecy, and deliberately obfuscating code, is not uncommon in the academic world as a result..... 

2

Share this post


Link to post
Share on other sites

I also imagine that for those with a heavy maths background they will try to name program variables as if they were doing so in an equation out of custom (since in equations everything is a letter and maybe a subscript).

 

True, but in general equation variables are named sensibly. I have trouble conceiving an equation mapping to this:

 

step_int((-ima*bxz-qjdiv*bxy)*xsp)
 

 

Nah it just looks like someone trying to use 1-letter variables, running out, moving on to 2-letter variables, running out, and so on.

 

Reasonable variable names are descriptive stuff like "delta", "x_prime", "du", and so on. But having multiple variables called "disx", "disy", "disxl", "disxr", "disx2", "disxr2" is unreasonable. It's insane. You have to look up their meaning to invoke them when needed, unless you know the code by heart (which should not be the case for even remotely self-documenting code). It might be good for a code-and-forget kind of project or library, but good luck maintaining this.

 

PS: or excessive precomputation, maybe.

Edited by Bacterius
0

Share this post


Link to post
Share on other sites

"du"?

 

Change in the variable "u". For a physics library I can see that coming up and people would know what it is referring to (if the "u" variable is clear, of course). Maybe "dt" is a better example (change in time, and the ubiquitous update(double dt) function signature)

Edited by Bacterius
0

Share this post


Link to post
Share on other sites

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

1

Share this post


Link to post
Share on other sites

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 [i]expected[/i] 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) -_-

0

Share this post


Link to post
Share on other sites

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.
1

Share this post


Link to post
Share on other sites

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 wink.png

 

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
1

Share this post


Link to post
Share on other sites

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 wink.png

 

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 happy.png

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

 

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0