The code mantra
First up, these are my humble (not really humble) opinions, and I'm always looking for better knowledge, and it may change from time to time.
Lets dive into what this is all about
So first up, you are probably a programmer , with anything from 20 + years of experience or may be a total new guy, but that does not matter, after the "introduction" you will all be the same, because a super programmer does not arise from age, but from understanding.
So lets start with one of my favorite contraversal way of thinking, which I believe is one of the most valuable way to always keep learning, and to always improve:
you are not an expert, you are closer to being new than experienced
...and wow that will hurt so many people, its ridicules! Like, one should not look down on one self right ? certainly not!!! But most bugs, most bad code (and a lot of other small "bad" things), will really stand out to a new person, because they do not have the understanding of the 5 lines of "ultra smart (complex)" code you composed, and you will not 6 months later when you look at it again. However, to notice ones one mistankes, and to always improve what one have created, one must also take the reverse / different view, as a new pair of eyes.
Once you start thinking about your code this way, you will get scared, by you starting to notice all the stupid small bugs, bad naming, bad behavior, shortcuts you have taken, leading to just bad decisions.
The more the better
So as a next step, why not close your eyes, and think for a moment, about all the "Nopes" and "not allowed" things in programming you are used to, feel them to the full extend, and then open your eyes again, cause really,
Every pattern, every style, every design is just another part of your "toolbox"; nothing is a useless piece.
Again, most people will say, "you cannot use a, b, or c in this and that", which properly is not that bad, but its the wrong way to view a,b and c; since its just in a context, not in general. Everything can be used for good (and solve the problem you are trying to solve), or it can be bad (the dark side).
Take the common way to view design patterns;
A lot of people do not believe in them ,do not know them , or have not tried them. Now the first step into the dark side is NOT to try stuff out. the best experience is hands on... and no, even if stack overflow have said 200 times that is a bad thing, that might not hold true for your particular case.
Now I could make a whole book about design patterns, so I will keep it short, by stating that most people need to know design patterns, and yes, they will be far more effective than what you know of, they will sove so many headaches its stupid for not trying it out. That said, over -(engineering) or designing is also a problem... every extreme is a problem basically, but some things are to be considered, first of all, anything that requires a magnittue (as a new person) of time understanding,properly needs a (re)design , you do not know the future, the changes will come (invasion of the changes), but if you do know something about the future, then do not be afraid, that is a luxury. other than that, THINK !! You already know that this UI / Controller / wounder class, will change, why bother either over designing it or not applying any design ? like there are so simple rules / ideas for this, and the short list is: - only 1 ? well keep it simple, it can stick together if you like (designing this will properly confuse people) - only 2 ? well, depends if you have any idea about more ? if so design, if not, then its really depending on the complexity (if its simple by nature, then keep it simple and together, if not, then design / separate , simplify though small individual parts). - larger than 2 ? well short version; DESIGN IT with a pattern is properly the only way to manage anything this "large". if you like your "if else" (or switch :O ) statements, that much, then you are violating a lot of very well thought principles
excuse me, principles ?
Yeah, so there are so many software development principles, that you could make a bible, but that would fuck people way to much up. So lets instead keep it simple (so the new guy can actually understand it, or in lay mens terms: everyone);
We like change by addition , not change by modification
- why ? cause changing stuff that works is a hurtful process, and second, tests might have to change, and last you might introduce new bugs , for working code .. (this is from the TDD / design pattern world).
Keep it as simple as possible.
- why ? cause you will forget the magic, new guys cant read it, and bugs will hide in every complex corner. most likely you are over engineering your code. (but some complexity for the overall simplification of a program might be a perfect solution, say a small helper, with a good name, and good comments, could potentially make a lot of code simple, by being the only complex function, brilliant ! )
documentation is a friend, for you and then next person
- why ? com on, it takes a few seconds, to save yourself an hour next time you look at it..
learn the language, domain, and design patterns. (and your own failures / mistakes) *why ? cause without these things, you are properly not really ready for the full blown challenge of a 2016 scrum / kanban based highly agile development; you will use them every day !
Nothing , and I mean NOTHING, is perfect, and every framework or system can be improved, or even be wrong , say "how to do a,b and c". In the end it is just other peoples thought, and since everyone is a newbie, then we can all improve on it, and learn from it. Every code, every bug have a story, a good side and a (dark) side! The trick is to learn both, and understand why and how it got to be "wrong" or "right" (notice that right and wrong, are both dangerous words in world where you can do one thing in a million ways).
And of cause, stop being hardcore on one particular solution, it might be that you are to "religious" about a style, or solution.
- why is this bad, if it keeps all the code the same and ........ ? it turns out you are actually limiting yourself rather than understanding your context, as said before, nothing is a useless piece, and in this context, the other solutions might actually be what you truly seek; SO LET GO OF YOUR OWN LIMITATION, BE FREE ! solve the world !! Do not let yourself be the old man in the corner with only half an eye (of opinions).
To sum up for now ?
So as stated in the start, this document will get updated. This is currently the finish line, for the 2 % of people not getting so offended they either try to hack me or kill me. Yes I do not posses the normal beliefs and neither should you! the more books and people who are VERY experienced or about programming style, will eventually tell you something about, do not just accept "yes or no" , THINK !! and if you think, most of the "yes and no" are in a context, and most of the time, just stems from bad (or good) experiences; but in fact, as stated so many times, do not limit your toolbox, be smart, be simple, and most importantly , learn and improve, you are not perfect, but neither is any, go now, learn, learn by failing, try magic stuff out, revisit old code (and cry, either because you realize how bad it is or how good it is ) and do not stop, nothing is impossible !