[kr0]

The comment at the end about this being acceptable leaves me wondering. I started programming in 2013 and doubt there was once a time where "bad" coding was ok. Surely there was always someone on the other side of the fence. I suppose when it comes down to it, there is getting it done and getting it done today.

[louthy]

As somebody who was working in the games industry at the time (as Playstation 1 engine guy), the amount of hoops you had to jump through to make something go as fast as possible was enormous; and sometimes best practice falls by the wayside. The way your game stood out was to do more than the others, I remember hand optimising my C written engine into R3000 assembler and made it fit in 4k so it could fit in the R3000 instruction cache. This would involve manually writing concurrent operations where I'd use the 4 cycles it took to access something from memory (which meant 3 spare cycles waiting) to do other operations. It certainly wasn't pretty, but it broke Sony's own figures for how many polygons could be rendered per frame. That stuff mattered at the time, because doing more per frame meant the game could do more - nobody was going to thank you for pretty code that was slow.

As well as that, the industry was very much a cottage industry at the time, many programmers were self taught and came from an era where one person would make the entire game. I was one of those programmers, and in the days before you could readily find information online about how to do things 'correctly' you found your own way (no Google, no StackOverflow, ...).

Would I want to go back to writing code like that today? No way. But I understand why it happened.

I put 'correctly', because even today we don't know how to write code. It's still an open question, and anybody that tells you they have the 'one true way' needs some extraordinary proof - otherwise it's just arrogance.

My preferred method these days is functional, but after 30 years of programming - starting from a BBC Micro (8bit, 32K of RAM), I am still learning. Mostly becoming a good programmer (in my opinion) is learning to deal with the inadequacies of the wet-ware between your ears. It's all coping strategies for the complexity of the problems we're trying to solve today.

[gnarbarian]

Best practices have been evolving since the dawn of programming. Much like today the technical culture at a given organization is the biggest influence on the quality standard for code. There are some places that still consider goto acceptable just like you can probably still find a doctor somewhere who will use leeches.

At the same time many things are considered taboo for trendier reasons that don't necessarily hold water. Many aspects of Functional programming for example were considered heretical during the heydays of Object Oriented programming until the pendulum started to swing the other way.

So what is considered a Taboo practice ebbs and flows with superficial trends in the industry as often as it does for reasons grounded in solid engineering.

Regardless though, the biggest influence on what is acceptable at any given time is the technical culture at an organization.

[louthy]

> There are some places that still consider goto acceptable

How about the C# compiler? :)

https://github.com/dotnet/roslyn/blob/56f605c41915317ccdb925...