Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (497)
Games in Android Showcase (114)
games submitted by our members
Games in WIP (563)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Ever forget how your own code works?  (Read 1130 times)
0 Members and 1 Guest are viewing this topic.
Offline Rayvolution

JGO Kernel


Medals: 199
Projects: 2
Exp: 1 year


Resident Crazyman


« Posted 2014-03-12 06:48:11 »

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

- Raymond "Rayvolution" Doerr.
Retro-Pixel Castles - Survival Sim/Builder/Roguelike!
LIVE-STREAMING DEVELOPMENT: http://www.twitch.tv/SG_Rayvolution
Offline trollwarrior1
« Reply #1 - Posted 2014-03-12 06:53:05 »

Yea of course, but even the comments don't work.. The only solution for me is to write simpler code..
Offline EgonOlsen
« Reply #2 - Posted 2014-03-12 07:43:05 »

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.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline VIrtueeL
« Reply #3 - Posted 2014-03-12 07:51:30 »

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

i do devlogs and i do tutorials check em out
https://www.youtube.com/user/InidDevo
Offline Elusivehawk

Junior Member


Medals: 1
Projects: 1



« Reply #4 - Posted 2014-03-12 09:11:39 »

Sometimes, if I abandoned the project a while ago, but I can usually relearn my code in a fairly short amount of time otherwise.
Offline Varkas
« Reply #5 - Posted 2014-03-12 10:34:39 »

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.

if (error) throw new Brick(); // Blog (german): http://gedankenweber.wordpress.com
Offline StrideColossus
« Reply #6 - Posted 2014-03-12 10:50:06 »

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!
Offline Gibbo3771
« Reply #7 - Posted 2014-03-12 11:00:22 »

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 Cheesy

"This code works flawlessly first time and exactly how I wanted it"
Said no programmer ever
Offline opiop65

JGO Kernel


Medals: 154
Projects: 7
Exp: 3 years


JumpButton Studios


« Reply #8 - Posted 2014-03-12 12:26:16 »

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!

Offline ricardo

Senior Member


Medals: 2
Projects: 3



« Reply #9 - Posted 2014-03-12 13:41:43 »

@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).
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Oskuro

JGO Knight


Medals: 39
Exp: 6 years


Coding in Style


« Reply #10 - Posted 2014-03-12 15:02:12 »

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

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:
1  
2  
3  
4  
public double pmtr(double r)
{
   return 2.0d * 3.1416d * (r * r);
}


Not So Bad Example:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
/** 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:
1  
2  
3  
4  
5  
public double f_a_p(double var)
{
   r*=r;
   return 6.2832d * r;
}


Offline lcass
« Reply #11 - Posted 2014-03-12 15:58:59 »

yes thats why i make like 100 classes to create a button xD
do you use it with supers like Component > GUI > graphics component > button or button>button.....
Offline gouessej
« Reply #12 - Posted 2014-03-12 16:20:42 »

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.

Offline StrideColossus
« Reply #13 - Posted 2014-03-12 16:33:47 »

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

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

Example taken from one of my projects:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
...

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

Offline junkdog
« Reply #14 - Posted 2014-03-12 17:45:14 »

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.

artemis-odb: bugfixing and performance optimized fork of artemis ECS
Offline philfrei
« Reply #15 - Posted 2014-03-12 19:55:38 »

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.

"Greetings my friends! We are all interested in the future, for that is where you and I are going to spend the rest of our lives!" -- The Amazing Criswell
Offline SwordsMiner

JGO Coder


Medals: 3
Projects: 2
Exp: 1 year


The one and only.


« Reply #16 - Posted 2014-03-12 20:51:58 »


My pet peeves:
  • Magic Numbers* are the silent enemy, exterminate them with extreme prejudice.

Not So Bad Example:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
/** 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);
}



Math.PI?!?!                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   

If I made you laugh, helped you at all, or did something cool, I only ask that you smash that appreciate button with your nose.
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

BurntPizza (22 views)
2014-09-19 03:14:18

Dwinin (35 views)
2014-09-12 09:08:26

Norakomi (62 views)
2014-09-10 13:57:51

TehJavaDev (88 views)
2014-09-10 06:39:09

Tekkerue (43 views)
2014-09-09 02:24:56

mitcheeb (65 views)
2014-09-08 06:06:29

BurntPizza (47 views)
2014-09-07 01:13:42

Longarmx (35 views)
2014-09-07 01:12:14

Longarmx (40 views)
2014-09-07 01:11:22

Longarmx (36 views)
2014-09-07 01:10:19
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!