hah, yes thats funny.
the 80 columns are actualy refered to as "what one can overview fast"
I guess they neither had stuff like indention nor class hirarchies in mind with that.
imho 120 columns is ok, where there shouldn't be more than 80 characters filled.
the c++11 -auto feature comes to aid here, at least in many cases you can better adhere the DRY-rule using that.
If the type isn't present in that line, i'd discourage using auto, since the source becomes harder readable if you don't know what that specific type pulled from some obscure getter actually is, and what to do with it.
I guess they neither had stuff like indention nor class hirarchies in
mind with that.
Nope. I'm pretty sure nobody was writing Python code on IBM punch cards in the late 20th century.
What screen width is *actually* used for programming these days?
I actually use 80, because on a typical 1080p monitor I can throw two windows side by side and compare test driver with implementation, or client with library, etc...
imho 120 columns is ok, where there shouldn't be more than 80
yeah, we use 120 as a standard, especially our UI guys, but my intellij autoformat seems to want to stay on 80 anyway, and I have not seen fit to fix my broken settings ;) (see previous post)
Huh... I haven't really given that question as much thought as I should.
I just sorta use whatever width I feel I need, and try not to get too ridiculous.
If I see it getting too ridiculous, I assume I am probably making some kind of mistake, and try to find ways to refactor the code a little to make it more modular.
But, sometimes, I don't feel I have a lot of choice... maybe I'm using code from somewhere else, or whatever. Then I just learn to deal with the width problem.
I'm trigger happy with the auto-format, and Intellij will happily re-wrap most lines in .java to 80 (with exceptions for things like long comments.)
This is **not** reliable for .groovy, intellij will alter your code semantics by adding newlines in places that change the code meaning (due to semicolon inference...)
Howto disrupt your contributing community:
Ahh yes, the old "beat the hornet's nest with a stick" technique. (Advanced trolling, 3rd semester)
google some of these and you will see them appearing in real-world open source projects...
it seems it worked out: http://orientdbleaks.blogspot.de/
database software is at its best when it's old and boring.
and then sometimes you need something super-scalable and lean. I am still not a big fan of NoSQL, I like my indexes automatically maintained and my data normalized, thank you. But there is something to be said for the auto-sharding of AWS DynanoDB if you know you are going to need something that really screams.
(And the SimpleDB pricing model can not be beat, but it may not be around for much longer, and the programming model is still not as good as SQL)
If your want lean storage for data, RDBMS might not be the winner (assuming that is the only criteria).
while libcitadel as base and many parts of citadel already embrace object oriented designs,tihs is an interesting read:
anno 2015: Microsoft Visual Studio implements snprint()