Ever forget how your own code works?

Sometimes, although I feel it’s kind of rare, I will find myself working on a project and after a good amount of time I may go back to my old code to change/improve it. Although once I head back, I fumble around in the code trying to figure out how it works again. I don’t do this with all my code, but there has been times my more complicated code confuses me when I go back into it after several weeks/months and I have to give myself a refresher on how it works.

To prevent this, I’ve started adding more comments to my code, but I was curious if anyone else has had this trouble? :wink:

Yea of course, but even the comments don’t work… The only solution for me is to write simpler code…

This almost never happens to me. My code follows my own twisted thinking and that is still the same after weeks, months and even years. So i find it very easy to grasp what i did in the past.

yes thats why i make like 100 classes to create a button xD

Sometimes, if I abandoned the project a while ago, but I can usually relearn my code in a fairly short amount of time otherwise.

It happens. One time I was not even able to find out how the thing worked, and I had to replace it by new code when I wanted to make a change.

Comments are your friend, I’ve learned.

Agree with previous posters - I’ve learnt (the hard way) that comments are your friend, even if the code you’re writing is only ever going to be seen by your own eyes, it’s worth having the mindset that you’re writing code for someone else.

Unit-tests are also good documentation, essentially they explain how the code is to be used (as well as obviously testing it works!), which is a good reminder when you come back to it and think WTF!

Heh I comment my stuff to SHIT, literally comments above every loop, if statement, switch block/cases…Every method has a detailed javadoc to it.

I still sometimes look at code and despite how well written the documentation is for it I say to myself “How the fk did I get that to work?!”

It happens, once you adapt a style you should be ok. It happens a lot if your learning new techniques, I was learning how to read info from files such as images and text files and perform algorithms with them, the algorithms were getting pretty big and coming back the next day to work on it I would get confused.

Keep at it :smiley:

No, not really. I used to sometimes. I comment my code very lightly, but I try to use very descriptive but short variable/function names, and I use those names over and over again in different projects so I know exactly what that variable does or what that function is etc… Of course, I will have new variables and function names, but that’s where comments come in handy!

@opiop65, same here.
But sometimes even with good variable names I lost myself if the project is too big.
In my Dominoes game I spend some time looking around to know how some stuff works before I release a new update. Maybe I have 1000 lines of code just to know where to put the next piece on the table (must check horizontal space, vertical space, last piece number in each corner, pieces size, etc).

[quote=“opiop65,post:9,topic:47385”]
This. Whenever I use placeholder variable names (like “aux” “temp” or single letter variables) I, invariably, get into trouble later.

Comments are very important too, but they need to be well structured or else they add to the confusion.

I’ve taken to using the javadoc comments at the start of a method/class, including a concise description of what is going on (with all parameters documented) rather than inlining comments all throughout the code (some inlining is still used, but it isn’t the bulk of the comments now).

Another technique is to properly encapsulate functionality. Having a single function do everything is a mess, splitting into smaller chunks can make it more readable and sometimes gasp even reusable.

In any case, in my opinion/experience any complex project you will have to re-learn when you get back to it after a while, so writing it like you would write documentation for someone else to take over will minimize the re-learning period, and also be great training if someday you expect to work as part of a team.

My pet peeves:

  • Use some decent Logging solution, log lines also serve as documentation.
  • Do NOT just capture generic Exceptions when you can predict what specific exceptions will be thrown. And if you do, LOG THE TYPE.
  • Magic Numbers* are the silent enemy, exterminate them with extreme prejudice.

*Magic Numbers: Whenever a value (not necessarily a number) is hard-coded somewhere in code. I obsessively turn said values into properly defined constants, which means I won’t forget what the number/value means, and I can easily search the value when needed.

Bad Example:


public double pmtr(double r)
{
   return 2.0d * 3.1416d * (r * r);
}

Not So Bad Example:


/** Easy as PI */
public static final double PI = 3.1416d;

/**Method Documentation: The formula is "2 * PI * RADIUS^2"
 *@param Radius A parameter being documented
 *@returns Return value also being documented */
public double Perimeter(double Radius)
{
   return 2.0d * PI * (Radius * Radius);
}

Kill It With FIRE Example:


public double f_a_p(double var)
{
   r*=r;
   return 6.2832d * r;
}

do you use it with supers like Component > GUI > graphics component > button or button>button…

Hi

At first, I use very explicit variable names most of the time. Then, I try to avoid writing very big methods or very big classes so that I don’t get discouraged when I have to fix a bug. After that, I write some unit tests (at least for the most complicated part). Finally, I write tons of comments, a Java documentation and sometimes some complementary documents to explain what I have been doing.

I can’t work for years on the same project without keeping my source code “pretty” to me.

Lot of good comments (pun intended) in this thread. ;D

I’ll throw one more in: using comments to ‘paragraph’ code.

Example taken from one of my projects:


...

// Create node for sky-box
final Node root = new Node( "skybox" );

// Construct sky-box
final CubeBuilder cubeBuilder = new CubeBuilder( MeshLayout.create( Primitive.TRIANGLES, "V", false ) );
final MeshBuilder meshBuilder = cubeBuilder.create( size );
meshBuilder.build();
final AbstractMesh mesh = sys.createMesh( meshBuilder );
root.setRenderable( mesh );

// Create material
final MutableMaterial mat = new MutableMaterial( "skybox" );
root.setMaterial( mat );

// Load texture images
final ByteBuffer[] buffers = new ByteBuffer[ paths.length ];
for( int n = 0; n < buffers.length; ++n ) {
    final BufferedImage image = imageLoader.load( paths[ n ] );
    buffers[ n ] = TextureLoader.toBuffer( image, false );
    ...
}

...

Obviously small, concise methods are better, but in cases where you have a long, linear method (like the above) and there’s little benefit in splitting it into private helpers, this approach breaks the code into easy-to-follow chunks (especially if you’re using an IDE with nice syntax colouring). The comments mean you can scan through the code relatively quickly to find the bit you’re after or to get an understanding of what’s going on.

It used to be a problem for me, but after a few years of coding it became increasingly more rare. Some time ago, I revisited my first game prototype - hadn’t touched the code in ~1.5 years, I was surprised that diving into it again was so painless.

I generally never comment my code, I prefer short methods and tiny, purposeful classes instead. I sometimes tell myself to make class- or package-level comments for complicated stuff, but rarely commit to it. The risk with commenting code is that comments can fall out of sync with the code (during refactoring and whatnot), becoming nothing more than a misleading distraction.

A good rule-of-thumb for writing comments is comment the WHY not the WHAT.

I’m reminded of the adage “a place for everything and everything in its place,” a phrase was written by and for grumpy adults who are losing their working memory edge, yes? (I include myself.)

Still, writing easy-to-read-and-understand code pays off big in $$ if you consider that time is money. Depending on the project, more time is spent in maintenance and revision or upgrading than in writing original code. So, it is a skill very much worth developing and much appreciated in a well-run workplace, even if you, personally, have eidetic memory and can currently hold it all in your head.

A similar thing often happens in art & composing, where folks can wonder “how in the world did I do that” and have doubts on being able to rise to the same level again. Then again, there are those that get a process worked out into a formula, and are very productive if not always the most inspired.

I find I get the most forgetful (both housekeys and code) when I am deeply involved in learning new tech or a creative project. I think there must be competition for brain cells or neural connections, that this is a natural aspect of “neural plasticity.”

I’ve read that lots of comments are a yellow flag. If comments are needed, the code isn’t self-documenting or the logic is too tricky by half and will leave one vulnerable to overlooks.