Jump to content

  • Log In with Google      Sign In   
  • Create Account

David Perfors

Member Since 15 Nov 2007
Offline Last Active Jun 08 2015 02:36 AM

#5232354 Best comment ever

Posted by on 02 June 2015 - 05:24 AM

// This code should be removed
// ....

where // .... is real code

#5232122 Code design/architecture

Posted by on 01 June 2015 - 03:03 AM

The most obvious ways of learning about architecture are: code reviews, asking questions and discussing code. But it in order to save time discussing some things it is a good thing to learn about design patterns and the SOLID principles.

#5173915 Your Prototyping Language?

Posted by on 15 August 2014 - 10:18 AM

I tend to use to prototype using the language of the project. So work related things are prototyped in C# and personal things either in C++, Python or Bash (what can I say, I am a linux guy :P).


When I don't have to write a prototype for some kind of visual problem, I will us unittests to ensure my code is correct.

When I am using C# and I only have to show some data, or try out some library to get it for me, I will use LinqPad, a program that makes it possible to use C# like a scripting languages... I haven't found anything like that for C++ though...


Even for learning parts of a language I will write unittests to make sure I understand how the language works...

#5062219 2D vs 3D

Posted by on 16 May 2013 - 01:40 AM

That being said, more and more projects who use 2D art, are starting to use 3D modelling software and some scripts to translate the 3D art to 2D sprite sheets.

#5056118 Code Formatting - Method Organization

Posted by on 23 April 2013 - 11:34 AM

With most IDE's it isn't necessary to organize methods at all, since you have several representations of the complete class structure and you can easily jump to the method you want.

That said however, it is possible that not everybody reading your code will use an IDE. So it pays off to organize your code in some way (other than how they popup in your head ;)).

I actually have serveral different ways of organizing my code, they depend on the language (C#, C++, PHP), the kind of project (work related, hobby or learning) and the mood I am in... but I try to organize methods with the same functionality together.


Typicly I don't mark regions of functionality with comments or the C# #region keyword. (because I think unnecessary comments are evil...)

#5054451 Code Review - Dice Game (No graphics)

Posted by on 18 April 2013 - 12:33 AM

This might help... you don't always have to think of methods as performing some vital function... sometimes you can have a private method whose sole purpose is to simplify the code in a more complicated public method. I often write little private methods that do various bits of non-trivial math operations, just to simplify the code.

Agreed, sometimes I make a method just for the condition of an if statement, especially when it is more complex or used multiple times.

#5054274 Code Review - Dice Game (No graphics)

Posted by on 17 April 2013 - 12:50 PM

Btw. for method lengths a good rule of thumb is methods between 3 and 7 lines, especially when the logic is complex, you want less lines.

I'm always afraid that I'm going to have too many methods in my program, so would I clear this up by making custom classes, and then just creating an object that can reference them?

I don't think you can have too many methods in a program. As is said before, your class should have one responsibility, but your methods shoud also have just one responsibility. Besides that, not all methods have to be public.

That being said, sometimes there are reasons to make a method larger than usually. This could be for readability or performance.

I can recommend the articles, videos and book of Robert C. Martin about "Clean Code". It is a relative old book, but still very usefull to read.

#5054108 Code Review - Dice Game (No graphics)

Posted by on 17 April 2013 - 12:33 AM

I agree with most of the things Indifferent says, but I want to add a few small things.


All methods are static. Basically this means there is no Object Oriented programming, which makes it harder to break things apart. I think it would be a good idea to try and find a book that discusses Java and OO.

Logic and UI are not separated. This is along the lines with Indifferents "Class length", but with a different angle.. When you separate the logic from the actual UI output it will be easier later on to try and add a Graphical layer, besides that it will be easier to test your logic using unit tests.

In the rules() method you have multiple calls to System.out.println(), and although it is probably a matter of taste, I would combine the complete string and print it all in one println().


Btw. for method lengths a good rule of thumb is methods between 3 and 7 lines, especially when the logic is complex, you want less lines.

#4940860 What I should know / learn to pursue a career in Programming?

Posted by on 17 May 2012 - 01:44 AM

Depending on what you want to do as a programmer, you don't actually need Advanced Maths nor Physics, although it could be usefull some times...
Knowing a language (or more) is great, learning the concepts like Object Orientation, SOLID, Test Driven Development, etc and learn them really well is much more usefull. When you know those concepts (which you have to learn using a language of course) you can learn any language within months.
The problem is that thos concepts are not tought very much in Universities (at least not in the Netherlands), so you have to do some self teaching or find someone who is willing to mentor you.

About learning how the languages work, that would be usefull sometimes, especially when you are using higher level languages like C# or Java. Those languages can do a lot for you without you knowing exactly what happens. When there goes something wrong, you really need to know what happens inside the language.

#4938282 Handling of game objects (projectiles, players etc)

Posted by on 07 May 2012 - 10:30 PM

I don't really understand why your code in ProjectTile.h should call methods from Game.h... Normaly I would call methods in the source file and not the header.

Although it is doable, I think the method you want to choose, is a complex one. A tile that handle an explosion and damage other tiles? Is that really the responsibility of the tile, or is that the responsibility of the "Explosion". It is a though decission and both ways are correct, but in my opinion, putting to much logic in an object is generally not a good thing.
Other than this I can't give you much advise...