Page 1 of 2

New CEGUI library maximum column length

Posted: Mon Nov 02, 2015 22:49
by Ident
Currently it is 80, but we don't work on 640x480 screens anymore ever.

Timotei suggested 100 or 120 since that is more typical.
I favour 120, which still seems small in my code window (Consolas 11, i m on 1080p) but seems to be the more modern standard to me.

Martin? Paul?

I know there is guidelines for literature that suggest even less characters but read coding isn't comparable to reading a book and I find 80 ridiculous, especially once there is some indenting going on, and even 100 can be tight at times, but 120 I can personally live with. In the end anything higher than 80 seems like an improvement to me.

Re: New CEGUI library maximum column length

Posted: Tue Nov 03, 2015 08:36
by CrazyEddie
Greetings!

This post will not be one that says anything along the lines of "n columns is the absolute maximum we should allow", instead it will go over the main reasons that a limit was established. Also I will mention that at one point in time I was the undisputed king of long lines, though I did come to realise the horrors of 200 character lines eventually :)

First, the limit is absolutely not related to screen real estate in any way - so whether someone is running at 640px or 4000px that is irrelevant. The only argument one could make in this area is that a line length limit allows people to have files open side-by-side, such as header and related code file (in before multi-monitor argument).

In my eyes, the limit exists for two (kind of related) reasons. Firstly it encourages what I will call "thoughtful coding". This might be better understood if i state my opinion of the opposite, no limit, approach. In my opinion, not having a low-ish limit encourages sloppy coding: long lines that the eye finds hard to follow, if statements with totally ridiculous numbers of conditions chained together, and of course, a personal favourite, obscene levels of nested if/for/while constructs. Having a low line length limit effectively disallows these horrors to exist and encourages us to create better structured and readable code (just better code, overall).

And that leads to the second point, readability. I know you said that it's code and it doesn't need to read like a book. I disagree. Having well structured, even beautiful code, is a pleasure to read and of course it's far, far easier to find bugs and other issues when your brain does not start zoning out after two minutes of looking at long lines.

Anyway, that's my point of view. Make of it what you will :)

CE.

Re: New CEGUI library maximum column length

Posted: Tue Nov 03, 2015 08:54
by YaronCT
Imo we shouldn't limit line length in order to force the programmer to create better structured code. For that purpose there's code review, which Lukas does very thoroughly for my pull requests :wink: . Indeed, sometimes long lines imply bad programming style, but I think there are cases where lines longer than 80 or 100 characters are the best way to format the code. I don't wish to inflame a political argument, but being a liberal I don't like it when I'm forced to do something which isn't necessary to force :wink:

I've suggested 100 characters in order to be conservative, but if u agree to go for 120 I'd even prefer that. And that's despite the fact that my eyesight is a bit weak and in the editor I only see 118 characters in a line of code (even though it's a 21'' screen with 1920x1080).

Re: New CEGUI library maximum column length

Posted: Tue Nov 03, 2015 18:49
by Ident
CrazyEddie wrote:And that leads to the second point, readability. I know you said that it's code and it doesn't need to read like a book. I disagree.


Optimal book line length is considered to be 50-60.

Code readability, I am all for it! But set 50-60 in your code editor and look at some of the more elaborate code parts in CEGUI. We would have to rnm all our clss to shrtr nms to be bl to pl ds ff. This will inevitably lead to code looking along the lines of

Code: Select all

rflNm = x->blrglGast()->mngrCl()
if it was enforced. Is this more readable? I say NO! That is what I meant with that we don't read code like a book. I would prefer to be able to read code always like a story. This however requires meaningful names, which will normally quite often get long. I like to have long variable and function names but in my opinion this is impossible with a 80 char limit in most of the code.

I also believe it is impossible people to make people write thoughtful code simply by putting a char limit into place. In the worst case, it might even make it worse by inducing ridiculously shortened variable and function names. The only way to make em write nicely is by not letting them do otherwise, i.e. not merging any code that is not readable, and we do this pretty well. Also anybody who worked on old code they wrote should know how important it is to be readable, and this is something that just comes with experience. Last but not least it can help people to read the book Clean Code. But anyways, my point stands that a char limit simply won't help this specific cause.

That said, most of the time I think I could live with the limit set to 100 instead of 120. I tried to put the line to 100 in my editor and I feel like this is quite managable in regular cases. But then there is often lines like this:

Code: Select all

d_tagHandlers[VertAlignmentTagName] = &BasicRenderedStringParser::handleVertAlignment;

This has 4 space indent and there is only around 6 characters left to the 100 limit. Now I would argue this is unshortenable and perfectly readable code. Imagine this function had parameters on the right expression for the function. It would immediately exceed the 100. I would really hate to make an extra line after the "=" because that just seems ridiculous to me. Because of these cases I am still in favour of the 120 ;) Long live long variable and function names!

yaronct wrote: don't wish to inflame a political argument, but being a liberal I don't like it when I'm forced to do something which isn't necessary to force :wink:

There is many types of liberals and they follow mostly strictly opposing views. The national liberals have little in common with social liberals or with green liberals and there is also economic liberals, among others. I would therefore consider it somwhat dangerous to call yourself a "liberal" ;) or people will associate you with exactly the wrong things.

Re: New CEGUI library maximum column length

Posted: Tue Nov 03, 2015 20:18
by YaronCT
Ident: Yeah, I've tried to understand what "liberalism" is from Wikipedia and have found it to be vaguely defined.. Anyway what I mean, is the liberty to do anything u want as long as there isn't a very strong reason to forbid u to do so. If there's a better word for it, plz enlighten me..

Re: New CEGUI library maximum column length

Posted: Tue Nov 03, 2015 20:21
by YaronCT
Ident: And w8 till u c my next project, I have a 64-character identifier... :lol:

Re: New CEGUI library maximum column length

Posted: Tue Nov 03, 2015 20:31
by timotei
I have to say that CE managed to provide me with a much wanted argument for lower column length :D

I think that the "rule" shouldn't be a hard rule, but rather a guideline to be taken into consideration as much as possible.

Re: New CEGUI library maximum column length

Posted: Tue Nov 03, 2015 20:35
by Ident
yaronct wrote:is the liberty to do anything u want as long as there isn't a very strong reason to forbid u to do so.

That is liberalism, but the question is where does liberty end. Where it hurts others, maybe? Maybe a 80 char limit hurts me. Maybe a 120 char limit hurts timotei.

Let's take the 50 char limit as target, it hurts everyone equally. I am an egalitarian.

Re: New CEGUI library maximum column length

Posted: Wed Nov 04, 2015 16:24
by Kulik
I am with CE on this one. Huge lines encourage super nested code that's hard to debug and navigate.

Re: New CEGUI library maximum column length

Posted: Wed Nov 04, 2015 16:31
by YaronCT
Kulik: A new line may imply a very nested code, which may imply bad code. But this is not always true. There r cases (which Ident gave examples to) where long lines r the result of good coding style and make the code more readable. I don't think the way to distinguish bad code from good code is by strict laws, but by code review (which is done anyway).

timotei:
think that the "rule" shouldn't be a hard rule, but rather a guideline to be taken into consideration as much as possible.

Well, I think that if there is a rule, it's better to make it a hard rule, otherwise it'll be really complicated to decide when the rule should be broken. I think we should go for a large limit, like 120, which is how many columns almost all developers are able to see in their editor, and make this limit strict. Using the limit to enforce this kind or another of coding style is something I don't find good.

Re: New CEGUI library maximum column length

Posted: Wed Nov 04, 2015 19:19
by Ident
Kulik and Paul, can you be more precise on what line length you would prefer? What about 100?

Re: New CEGUI library maximum column length

Posted: Thu Nov 05, 2015 13:49
by CrazyEddie
My personal preference as an individual is 80 columns. It's what I use(d) for the majority of the time when I worked on CEGUI and it's what I use for any code I create currently.

Do I think 80 columns is 'best' for CEGUI? Yes. Will I attempt to impose my will upon a project for which I no longer actively produce code? No, of course not. You guys need to do whatever you think is right.

CE.

Re: New CEGUI library maximum column length

Posted: Thu Nov 05, 2015 19:16
by Ident
Let's leave it at 80 then. I will set my line to that limit but be aware that sometimes it will and has been exceeded, not just by me ;)

Re: New CEGUI library maximum column length

Posted: Thu Nov 05, 2015 20:39
by YaronCT
Ident: I'm a bit confused. We leave it at 80, but be allowed to exceed it?..

Re: New CEGUI library maximum column length

Posted: Thu Nov 05, 2015 21:13
by Ident
yaronct wrote:Ident: I'm a bit confused. We leave it at 80, but be allowed to exceed it?..

No. But I m a rebel

To clarify: Rule is rule. But if there is a reason to break it, and no way around it, then imo break it.