Here were mine to refresh your memory:
Is there anything I missed? Is there anything you disagree with?
3 Likes
A few things I try to abide by are as follows:
- Write out a basic architecture plan before actually coding. Itās okay if things change as you implement, but itās nice to have a starting guideline.
- Every rule has its exceptions.
- If you are breaking a rule, make sure you have a reason better than āI just feel like this is an exception.ā Actually know why you think you should break it.
- Archive old code and ideas you are no longer using rather than deleting it. Some of those ideas could come in handy again.
- Try to make your Git commits like your classes/functions. Serving a single purpose that is well named. Makes backtracking a lot easier.
- Donāt refactor and iterate to the point where you are never getting anything else done.
Iām still working on doing these things admittedly, especially the first and lastā¦ Especially the lastā¦
3 Likes
The most important one: Always look for a simpler solution.
4 Likes
Looking forward to working through this list Sam.
My most important commandment has always been: think of those who will have to maintain your code (particularly because it may be you).
Back when I started coding (around 1995) we would do things like put our names in the coding block at the top of the page, maintain a version history (including who made the changes) and we were told to comment everything.
Version control software has obviously made the first part obsolete.
Iām still not sold on limiting comments.
I feel like that risk of comments being wrong over time is outweighed by the assistance they provide.
One topic in particular that I am interested in is your #9. Iāve had discussions with people recently about the Component Object Model vs Object Oriented programming generally and I may be wrong but it seems like this is where the topic is leading.
Another topic Iād be interested in is how Unity and Unreal implement design patterns out of the box.
My experience so far is that Unity lets you make as many mistakes as you wish, whereas Unreal is much more structured and doesnāt allow you to really go off track. It feels like you need to be even more aware of design patterns when working with Unity to provide your own level of discipline.
cheers
I think both are valid Object Oriented approaches. In fact I would say that Composition over Inheritance is an OOP specific commandment. But perhaps it is opposed to more ātraditionalā inheritance hierarchies.
I do like that Unity encourages and enforces Componentisation. Unreal really encourages use of heavy inheritance and themselves have pretty massive god-classes like Character. I donāt believe thatās good practice.
They certainly have more of their own frameworks and ways of working with things like the Controller-Pawn model. I hadnāt considered that a pattern until now but maybe I should include it!
1 Like
This is a great list. Iām looking forward to learning more about programming patterns since I am still relatively new to coding (started just over a year ago).
One thing I always try to do is write my code first, then refactor later. The perfectionist in me wants to get the code perfectly neat and tidy on the first try, but thatās not always possible. I think as a slightly less experienced programmer, itās really important to just get the code down on the page and working before worrying about any fancy refactoring or tidying up.
Forgot to add: I am also on the fence about excluding comments from code. I tend to leave some in, but then again, Iāve only worked as a solo developer so far so I havenāt had to worry much about them mucking up my code for others to read.
Thou shall not re-invent the wheel.
Thou shall sleep on it if all else fails.
Thou shall consult rubber duck before annoying others.
4 Likes
To be clear. Iām not advocating zero comments. Iām saying that you shouldnāt use comments as a crutch for bad code. You need to write code that reads like English first. Comments should aid the understanding by explaining āwhyā you wrote it that way.
3 Likes
Ah that makes sense. Thanks for the clarification!
1 Like
- Thou shalt commit they project to Source Control regularly!
- Thou shalt cache thy references when they are on the same GameObject
- Thou shalt not cach thy references when they are transient (from another GameObject, like, say the current target, that could change at any time.
- Thou shalt use descriptive variable and function names. (except for indexers and xyz)
- Thou shalt comment thy code, but only when the code is not explicitly clear (see above commandment), and never use non-useful comments (Iām looking at you, Unity Documentation Team!)
- Thou shalt not rely on strings for file paths (for thy files may wander when cleaning up your project)
- Thou shalt write D.R.Y. code whenever one finds oneself using boilerplate.
- Thou shalt organize thy classes into namespaces to avoid cross dependencies
Iām looking forward to working through this course gradually.
Typically with Unity Iāve thought it best when having a class to immediately abstract any new functionality I am intending to associate with the class into a function/method for clarity rather than leaving it in a start or update function that can be more ambiguous (even if it is a move class with a single move method that runs each frame update for example). Now, I am not sure if that goes against commandment five or not, and maybe a bit of commandment three when sticking multiple methods operating differently within a class.
Separately, Iām also kind of curious whether ECS ever really took off in Unity (back from almost a year hiatus) to any degree and whether these commandments would be applicable in that case.
I think itās still getting there slowly.
1 Like
Hi! sorry Iām late to the show,
I figured it would still be fun, and a good thing to form my thoughts into words to better help me learn to participate in these from time to time.
My biggest commandment if life as well as programing:
- You can always be wrong, and thatās ok!
I suppose DRY is already assumed in #5.
I thing Iād add:
- Always make it clear in what circumstances a method/function/procedure can reliably be called; and
- Keep track of loop variants and invariants.
My biggest one is, if something ever confuses me in the future, fix it. That might mean adding a quick comment to explain why some confusing-looking code is so confusing, or refactoring it to make it look less confusing, or rewriting the whole thing to be better behaved. But if it costs me several minutes now to figure out what the heck I was thinking, itāll likely cost me several minutes again and again in the future.
My second one is use source control. By making me commit stuff, I am better able to make my changes intentional. A random experiment that doesnāt pan out gets reverted much more easily if I can see that itās a change from the last version, and if something gets totally screwed up I can revert. Setting up a local git repo isnāt at all hard, and so long as I remember to keep things committed after making a reasonable update it makes life much easier.
And a third one, coming from Perl: Similar things should look similar, different things should look different. Applies to code, UIs, and all sorts of other stuff. If two functions behave very similarly, they should be structured similarly, named similarly, etc, but also built such that the difference between the two of them is completely obvious as well.
1 Like
These are so important! The number of times Iāve had an epiphany in the shower the next morning is crazy. Also, the rubber ducky has solved many a problem for me over the years!
1 Like
A few years ago, I sat down and wrote my Rules To Code By. It was broken into three sections: writing code, committing code, and working in a team. This is what I had for writing code:
-
Strive to write simple code
Simple code is easier to fit into a wider system.
Simple code is easier to fix when a bug is found.
Simple code is easier to maintain. -
Methods should not use many variables
Variables makes the function harder to use.
Variables makes the function harder to maintain. -
Use meaningful names for variables and functions
Meaningful names give immediate understanding to whomever is reading it.
Meaningful names are self-documenting. -
Name the class by the coding pattern it implements
The name immediately identifies the standard pattern for other coders.
The name constrains what the class can do. -
Use common libraries where possible
Common libraries are written by people smarter than you.
Common libraries are already well-tested. -
Check before creating new classes and methods
Checking prevents reinventing the wheel.
Checking prevents a bloated codebase. -
Use patterns already present in the code base
Existing patterns cut down the learning curve for the system.
Existing patterns are easier to maintain. -
Explain the āwhyā rather than the how with comments
The āwhyā gives a wider context to code.
The āwhyā doesnāt repeat what information is already present.
The āwhyā doesnāt need to change when the code does. -
When possible, use test-driven development
Unit tests give confidence that a piece of code works how it should.
Unit tests give this confidence when making other changes in the system. -
Maintain the unit tests that your code affects
Unit tests with commented out lines defeat the purpose of unit tests.
Unit tests that are ignored cause confusion as to why they are ignored.
Unit tests that are ignored serve no functional purpose. -
Be verbose with TODOs (and FIXMEs)
A verbose TODO helps to confer the mindset at the time.
A verbose TODO helps those coming much later whether it still needs actioning.
1 Like