3.16.2011

Coding Style in general

The more I read Google's C++ Style Guide, the more I wonder about their sometimes just silly formatting conventions. Technically, it's very well-explained and tought me some worthwhile facts I'll obey in the future. But if it comes to naming conventions and formatting... Geez, these guys are really nasty. 80 characters length limit? Personally, I don't see any reason for that in my projects. I'm don't remotely edit files of a space station somewhere in the depths of nil using VI or so, I usually sit in front a one or two files and profit from having a possibly fat block of high density code that wouldn't be comfortably readable with only 80 characters. Ok, ok - I'm not somebody how likes one-dimensional and lengthy codes. I prefere spanning it over all dimensions my head can offer me to understand, including the informational depth itself. To their defense: I don't write as much "diverse" code as they do - I'm one person writing stuff for graphics and video games in a highly generic and reusable manor. I like to keep it condensed to it's functional core instead of making it "too readable" for others. It's not that I don't encourage commenting code - I comment a lot, mostly cause I often forget what I wrote in the past, so I can recover anything and also their means including simple delete functions I may find inappropriate later though they play an important role at this point. I also use operators a lot, mostly cause I operate with a shitload of maths nowadays, requiring some syntax you can understand by just looking at the symbols. So yeah, I probably don't really understand such "conventions" . I only keep on reducing codelines vertically if it's highly redundant code with only small changes, I use abbrevitions for always-same parameter variables etc. It's all a matter of what you code I say. If I'd write only C code, I'd probably name identifiers differently, since there isn't any way to "batch name" whole blocks of definitions/declarations. This encourages me to think more about my personal guidelines cause I tend to forget useful things I did in the past - though most of the time I discover new, better things that go better by default. But so far I'm rather solid with formatting and technique in general.

Anyway, it males your head hurt to read stuff you totally disagree. How great it is to not work for Google. I don't squeeze my code into silly 80 characters, dumbass. Especially not such repetitve stuff like mathematical operators and so. But thinking about it, I started again to think about creating a LinkedList set instead of my self-managing one. The concept of having a "Tracers" for an array, which cover a set of entries based on settings and calling callbacks on a template class base is quite convincing for other classes, too, I think. There isn't much to define when speaking about "storage classes" like I like to call arrays, lists, etc. You got Arrays, Lists of all kinds, and then special tree variants (though a list can be thought as a tree, too). So since I nailed down an interesting way of mass-altering/scanning objects in every kind of such storages with a concept useful for once-implement-and-never-change codes, I guess I can keep on designing later storage classes in the same way. It took me some time to reach a point where it's close to all-inline implementation but with high flexibility during compile time. So it's a good idea to continue this... Unfortunately, I'm kind of a lazy bum these days. And this won't change til I feel so. It's great to have term breaks!

No comments: