5.07.2012

Some words about code cruelty

Starting in a company having some sort of programming does usually also mean coding conventions and trade-offs between your own coding style and the one used by everyone else as well as the convention your lead programmer defined for use in every project. To be honest, I'm quite a code nazi if it comes to my own work - though I try mi minimize that sort of behaviour if it comes to code written by others. But this time I can't hold myself back, it's just code cruelty at it's adolescent state! No politeness will be spared, no convention left unkilled by logic and analyzation. First of all, member variables. Normally you don't bother because you access object.member or object->member and you'll definitely know that it's a MEMBER and nothing else. Methods will be called using object./->member() and static member called via class::member because using an object to dereference the static member is most likely prone to evaluation side effects. Thus, you'll ALWAYS see what is and can use camel case or lower case or whatever to make it out very directly.without needing to prefix or postfix anything. But you know what? They still prefix it using "m_" and "s_". Wtf? It's not argument to dublicate the obvious except if you're dum enough to not beeing able to read atleast C code (where it's the same thing). Another point is ToUseUberlyLongWordsThatReallyDontTellYouAnythingAboutTheClass. I mean seriously, it's all so plain simple dum code that it doesn't make sense at all, just adding obfuscation. It's one of the reasons why I'll never wonder about this company's non-existing list of achieved projects. I've seen more unique bugs the last week than in my whole programming lifetime (making it clear how I try to avoid anything making the code unstable and unreadable instead of obfuscating it even more). An engine should ALWAYS catch stuff, check errors and report properly. It's creepy and disgusting to imagine how programmers produce so many hack-driven blocks of poorly documented code. I'm more than glad that I'm officially in the QA department and not there for solely expanding stuff. Seriously, I wouldn't have wanted to work for their programming department if I would've known how horrible their coding conventions are. Knowledge about platforms and 3D aside, this is simply a no-go but you'll have to stick with it because you can't change it. I even ask him why they do it this way and the discussion in ended quite fast with the lead programmer stating that he's making the rules, so that he can cope with it. I'd call him a bad loser for this one. Next time, this discussion should really be a bit more fruitful, shouldn't it? Well, atleast I know atleast one source of the problem: code completition. Name me single OOP programmer not working with code completition in strong C++ or Java OOP environments. Noone, ey? Yeah, that's just it. OOP programmers tend to clutter everything while stating that minimal and short-named symbols don't express what they do. They forget that a small subset of function of and structs is designed to exactly BE small and compact to avoid literal noise. I can't believe how ignorant and typical this is. And then they don't event check errors, can't live without debuggers due to that. It's a wonder that something works. And no, writing unsafe, obfuscated code that fails to work regularly is NO sign of a good programmer. Like if someone didn't take the time to really study a programming language to see why there are people out (like me) avoiding a long list of antique coding conventions that don't make sense. I don't talk about old conventions that make sense, that's totally respectable. But the whole world of OOP programmers is like a swiss cheese fill with acid. Yeah, call me mad for that, but the sheer utter truth lies behind the shiny walls of corporate identities. It's sad. Very sad. But don't think I'm gonna drop this company. There's plenty of room for subtile change which I'll hopefully introduce in one way or another. Especially if it's about bugs needing to get fixed - which I'll gladly do to prove that a lot of existing things just obfuscate code and programmer. However, I'd never doubt their professionality to be clear. There surely is a great pool of knowledge behind, but if it comes to programming... Well, let's just say that the qualities of a pro do not necessarily result in logic, rather in predictability and knowledge about one's skill.

No comments: