On 01/30/2011 07:17 PM, Andrej Mitrovic wrote:
The unittest topic is about to get derailed so I want to continue this silly discussion here.Wheres Nick? I want to see the CRT vs LCD discussion heated up again with Andrei claiming that LCDs are so Godlike but yet claims 80 columns is enough for everyone. 80 colums is an artifact of the old age. Just like the preprocessor is an artifact of the C language. And many other old things are artifacts. There's no reason to keep these artifacts around anymore. A couple of things, Andrei: 1. 80 colums is way too restrictive. 80 columns wasn't determined by some scientific method to be a good size for code, it's a product of limitations of the older generation hardware. Who will run a brand new language like D in a freakin' Terminal? Have you ever heard of the expression "limitations boost creativity"? That can be considered a good thing, if creativity is what you're after. In code, it's not. You're looking for clarity in code. 80 column limitations are good for C obfuscation contests and nothing else. 80 columns means people are going to *work around* the limit, by using hacks and workarounds to make everything fit in place. Do you really believe that programmers are going to spend any time at all thinking: *"oh this line doesn't fit on 80 columns. I should now spend some time thinking about how to improve and rewrite the design of my code. 80 columns really is the golden ration"*? If you want to see more files on the screen, get multiple screens. Is Facebook running out of money, can't they afford a few monitors for the C++ guru? Yes, I know you're not allowed to comment on that one. :) 2. A widescreen aspect ratio causes less eye strain. Wider code means the same. It doesn't have to stretch all the way to be effective, but 80 columns is too limiting. Do a Google search and read what people have go say about that. 3. Less columns means more rows. And generally coders *hate* it when they can't see a function that fits on a single screen. They hate having to scroll up and down. This common syntax form is a proof of that: void main() { void foo() { while (true) { if (done) { } } } } I find that unpleasant to read. Not impossible, but unpleasant. I can live with it though, but if you limit code to 80 limits that's going to become a mess to read. 3. It's 2010. Does your GNU/emacs still not support wrapping lines by word boundaries? Scite had this since the '90s, and that's not even an advanced editor. Vim supports word wrapping as well. Heck, I'm pretty sure you can customize it to wrap on whatever boundary you want to (although I'm only speculating, but pretty much everything in Vim is customizable). You can even customize how your cursor reacts if it's on an 'artificial' new line, one that has been wrapped. Isn't technology amazing? 4. Just how many files do you want to edit at a single time on the screen? We're not really multitasking beings, you know. Try using one of your hands and do forward circles, as if it were a wheel. With the other one do backward circles. And now use your foot to draw a circle on the floor. You're end up looking like a clown in seconds, and a bad one at that. Again, people who want to have documentation, and code, and IRC chats in display buy more computer screens. Why should your code have to suffer if you really want to do multiple things all at once? Bottom line: If you really want to set up a column limit that *everyone* has to abide to, then make a poll to see what everyone can agree on. I don't see why everyone has to cater to your rules only, regardless of what your professional experience might be. You're a big contributor to Phobos, but you're not the only one. I tend to believe that D is (or should be) a community effort, so please don't hijack D away from the community by forcing your own rules down to everyone else.
I think there is no need to establish a fixed limit. "Avoid long lines" recommendation in the style guide would be enough.
