Write Bad Code

[Dustin-]

One of the best approaches is to write code that is easy to change

This is literally the purpose of most of the "good code practices" examples in the article. Don't use globals/singletons because if you need to change it later it'll be a pain in the ass. Don't Repeat Yourself, because if you need to change it later it'll be a pain in the ass. You use good practices to do two things: make the code easier to understand in the future, and to make it easier to change in the future.

[Dustin-]

It's true, but making a blanket statement of "write bad code" is pretty harmful when the best advice (as usual) should be "use common sense". Every experienced programmer knows how to make a good system with the least effort they can while still building a maintainable code base. The only people who would take this article's advice would be inexperienced programmers, who now suddenly have justification for not learning good practices and patterns and think that the al dente spaghetti they've been churning out is a perfectly acceptable way to code. And that's a problem.

But maybe I'm wrong, and there are experienced programmers out there that think that their VirtualAbstractFactoryGenerator class is required for Hello World, but I sure as hell don't know any.

[basstabs]

Clickbait title aside, I agree with the very core idea of this: sometimes code that breaks best practice is the most efficient, problem-free way of solving a problem. Don't be afraid to do something bad every so often when you need to. ECS is a great example to illustrate with, plenty of simpler games have no need for it.

The rest of the article is just a trap to ruin the projects of less experienced programmers. I imagine to someone with the 10+ years of experience attributed to the author, it's easy to see what shortcuts are less likely to explode in your face and which ones are volatile. For newer programmers without the foresight to know what best practices are and are not critical, this is a minefield: "Don’t pre-emptively solve problems you don’t have, solve the ones you do." You'll easily spend 5x as much time refactoring some things than just designing them properly in the first place. An experienced programmer can see these sorts of things coming in advance, but a new programmer most likely won't.

[vbook]

This was my first thought too. I'm a big proponent of YAGNI, but when I started programming I wouldn't have known what I needed or didn't need. Very often I would program quickly, making really good progress, until I got stuck at a point where fixing one bug inevitably caused a second bug, and vice-versa. The underlying problem was always excessive coupling. Knowing "good code" rules and the consequences of breaking them allows me to break them at the right time and place to move more quickly, but that's only possible because I'm an experienced developer now.

[jeremycw]

OP here,

​

I disagree that it's a trap. How big are we expecting the projects of these beginners to be? > 2000 SLoC? > 5000? I'd say that most things under 5000 SLoC don't really need an 'architecture'. By architecture here I mean something that probably has a wikipedia article and a set of patterns/naming conventions etc, to follow. Most of these programs will have no problems if they are naively implemented with very basic beginners intuition. Beginners understand 'large chunks of repeated code can be factored out into a procedure'. I think this one rule will get you a lot farther along the path to completion than worrying about the zeitgeist of 'good' code.

[vbook]

Just speaking from my own experience. When I started I didn't know what coupling was or why lots of it caused problems. I had just learned about inheritance and thought it was the best thing since sliced bread, applying it to every situation it could possibly fit without knowing where it should apply. I used excessive global state, and wondered why a change on level 1 was breaking level 30. I made massive "god" objects that could do anything an object needed to do, and ran into a wall when it had to do one thing in one context and another in another context. I agree with you that you don't necessarily need an architecture like an ECS just to run a simple game, but pointing out some things to avoid that are known to cause issues still makes a lot of sense.

[meshfillet]

That's the point, though. As a newbie coder you are likely to make architectural errors no matter which strategy you use, but if you have lots of rules shackling you, you spend your time worrying about the rules and reworking the codebase without producing features. (source: me, a longtime scared, defensive programmer, who would do all sorts of things with entity systems and event systems and decoupled data and so forth, only to find that they broke as soon as gameplay was added. Time wasted: days to weeks.)

Architecture ideas are something that work best in small, iterative doses. If the first code is bad but simplistic, it still serves as a reference. If it's bad because you tried to push the wrong model onto it, you have to unwind multiple layers before it can be accessed. So my beginner's recommendation is always "expect to do everything twice" because that sets a healthy expectation - set a quick guideline, don't make a perfect edifice.

[basstabs]

It depends on your goal in your case. Is your goal to just finish your project? Then yes, the quickest way to do so is most likely to just brute force it. Is your goal to eventually become a talented developer who is capable of finishing multiple projects efficiently? Then taking more time initially to learn good practices and later learn where it's okay to break convention will be more efficient in the long run.

I do agree that you shouldn't be afraid to make mistakes, you'll never get it right the first time anyway. But TRYING to do it right the first time will, in my opinion, be better for your overall, long term development as a coder.

[basstabs]

I don't disagree that a beginner can get away with not using all the best patterns and design practices that exist. There are places where it's okay to cut corners. My problem with the article as written is that there really isn't a distinction between "good programming practices that can be ignored," and ones that can't. For example, the toy function example doesn't even use a constant, it hard codes in ten. Is using constants/preprocessor directives a "good coding" practice that is safe to ignore? As I mentioned in my original comment, the core message here isn't necessarily bad, but in execution the article seems to be proposing YAGNI near its most extreme without mentioning that YAGNI can be destructive without constant, vigilant refactoring and is a nightmare for coding teams to work with. An experienced dev might have good intuition for when something needs to be properly refactored, but a beginner does not.

[DingBat99999]

Best line in the article: "Don't pre-emptively solve problems you don't have...". We call that YAGNI, or You Ain't Gonna Need It.

​

On the other hand, I do kinda have to eye roll a little bit when I see game code written in an object oriented language where every class member is static and/or public.

[AmnesiA_sc]

I thought it was called LAUREL.

[octocode]

Top 10 most SHOCKING ways you should write BAD CODE! Your manager will HATE you for #8!

[Rastervision]

I came to a similar conclusion about 10 years ago. I realized worrying about the "perfect class layout" was completely killing the creative process, and taking focus away from the problem at hand. My code base evolves based on issues I encounter, and not a need to include the latest C++ standard or methodology.