Dear all,
[Despite today being April 1st, this is not an april fool's joke]
ever since the start of the Osmocom project, we have adopted pretty much 1:1 the Linux Kernel coding style.
Having a uniform coding style all over the project is important for readability, and from my point of view it doesn't really matter too much which style it is, as long as it is uniform accross the projects.
I'm still fine with the Linux kernel coding style for most parts, but I think we could consider allowing longer lines. 80 characters is still nice here and there, but maybe something like 100, 120 or even 130 might actually make the code more readable and permit us to use slightly longer identifiers without having to wrap every second statement in the code.
What do people generally think here?
Regards, Harald
On 01/04/2017 11:45, Harald Welte wrote:
80 characters is still nice here and there, but maybe something like 100, 120 or even 130 might actually make the code more readable and permit us to use slightly longer identifiers without having to wrap every second statement in the code.
What do people generally think here?
Not that I'm coding much on Osmo, well it says RFC.. :-) I have recently been making at attempt to clean up some python coding style using pylint and I have been wincing a little at the "standard" default of a line width of 79, although some arguments in favour do make sense.
My terminal is generally 120 -140 characters wide. I also use Sublime Text which usually displays 110 the way I have it. You mentioned something recently about why would anyone read code in a web browser, I find myself browsing code more and more on sites such as github, rather than getting a local copy, via clone or download and extract etc. - I had a conversation recently about how we tend more to lookup quick reminders of things on the web, even though there are local manpages. need to get offline more.. :) Anyway, github site handles 120 chars fine. I guess any issue might be more with gerrit.
k/
On Sat, Apr 01, 2017 at 11:45:17AM +0200, Harald Welte wrote:
I'm still fine with the Linux kernel coding style for most parts, but I think we could consider allowing longer lines.
The vim indenting rules help a great deal with breaking up lines[1], but particularly when strings or function argument definitions are involved, it's still annoying. There is no actual reason to choose 80 chars anymore. With the osmo-gsm-tester code I'm working on these days, I find myself not strictly enforcing the 80 characters rule, because it's annoying more than helping.
Just checked, the default way my terminals are arranged and configured ends up in 105 characters of line width (two terminals side-by-side in a tiling wm, with a font roughly ten times the size that Harald uses).
When I scale down one font size, I can fit 119... but...
My purely self-centered vote would be 100 chars -- or 105 ;) I guess even if we allow 120, most lines would stay within 100? A post some time last year pointed at a ruleset using 120.
With debug log output lines I would gladly allow "any" line width, though. Following the category and level is a nice and descriptive string, which almost always needs to be broken up without really serving code readability.
What do people generally think here?
+1 ("+20")
~N
[1] ~/.vimrc: if has("autocmd") augroup ccmds autocmd! autocmd FileType c set cin isk=a-z,A-Z,48-57,_ cino=>1s,e0,f0,{0,}0,=1s,t0,+1s,c3,(0,u0,\ 0,:0 autocmd FileType cpp set cin isk=a-z,A-Z,48-57,_ cino=>1s,e0,f0,{0,}0,=1s,t0,+1s,c3,(0,u0,\ 0,:0 augroup END endif " useful: 'visual'-select a long line and hit gw
I completely support extension of the line with. 80 characters limit is very annoying these days. 120 is a good number.
Please excuse typos. Written with a touchscreen keyboard.
-- Regards, Alexander Chemeris CTO/Founder Fairwaves, Inc. https://fairwaves.co
On Apr 1, 2017 12:45, "Harald Welte" laforge@gnumonks.org wrote:
Dear all,
[Despite today being April 1st, this is not an april fool's joke]
ever since the start of the Osmocom project, we have adopted pretty much 1:1 the Linux Kernel coding style.
Having a uniform coding style all over the project is important for readability, and from my point of view it doesn't really matter too much which style it is, as long as it is uniform accross the projects.
I'm still fine with the Linux kernel coding style for most parts, but I think we could consider allowing longer lines. 80 characters is still nice here and there, but maybe something like 100, 120 or even 130 might actually make the code more readable and permit us to use slightly longer identifiers without having to wrap every second statement in the code.
What do people generally think here?
Regards, Harald
--
- Harald Welte laforge@gnumonks.org
http://laforge.gnumonks.org/
================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Hell yeah!
The 120 would be a dream come true :)
I use emacs to visibly mark current 80 chars limit and it's about 1/3 screen estate on my rather old monitor.
On a related note: have anyone tried to use https://www.gnu.org/software/indent/manual/indent.html already to make more formal specification of what Osmocom coding style is?
On 01.04.2017 11:45, Harald Welte wrote:
What do people generally think here?
Hi folks,
The 120 would be a dream come true :)
To be honest, I feel very uncomfortable with changing the coding style. This would make the existing code look like a mess. If we really break with the 80 lines limit, we should only do it for new projects.
Since the 80 characters have a historical background, the new policy should have a historical background too. I would suggest to use 132 columns (DECwriter II)
regards, Philipp
That would only be true if all the code would have complied with the current policy of 80 chars. In reality it's not the case - in almost any given file you can find exceptions hanging beyond 80 limit. So the code is already mess in this regard.
On 03.04.2017 10:35, Philipp Maier wrote:
Hi folks,
The 120 would be a dream come true :)
To be honest, I feel very uncomfortable with changing the coding style. This would make the existing code look like a mess.
I like the notion of historical context... http://kleinekatze.de/lai9wiK4/DECWriterII.jpg ;)
Still I would prefer 120 or less for practical reasons. I assume none of us is using a DEC Writer to hack on Osmocom? :)
~N
On Mon, Apr 03, 2017 at 10:25:50AM +0200, Max wrote:
Hell yeah!
The 120 would be a dream come true :)
I use emacs to visibly mark current 80 chars limit and it's about 1/3 screen estate on my rather old monitor.
On a related note: have anyone tried to use https://www.gnu.org/software/indent/manual/indent.html already to make more formal specification of what Osmocom coding style is?
Could be nice to have this in the light of: http://programmer.97things.oreilly.com/wiki/index.php/Automate_Your_Coding_S... We would have a bunch of cosmetic commits to once apply a consistent style everywhere from 'indent', and we'd probably have an amount of bikesheds until we agree on a specific 'indent' configuration. From then on we would have a guaranteed fixed coding style. But we'll probably also have to do many more patch edits from breaking the style in gerrit submissions, and it would also erase the comfort of being able to let a cosmetic issue slip by. 'indent' is only useful if all code already adheres to its style (otherwise it adds numerous unrelated cosmetic changes). Would have been nice, but not sure if it's worth the added effort to introduce it now...
~N
On Sat, Apr 01, 2017 at 11:45:17AM +0200, Harald Welte wrote:
[Despite today being April 1st, this is not an april fool's joke] nice here and there, but maybe something like 100, 120 or even 130 might
It sounds to me like most opinions converge around 120. The collected opinions from this thread:
"My terminal is generally 120 -140 characters wide. I also use Sublime Text which usually displays 110 the way I have it."
"github site handles 120 chars fine"
"I can fit 119"
"A post some time last year pointed at a ruleset using 120."
"120 is a good number."
"I'm fine with either 100 or 120."
"The 120 would be a dream come true"
"I feel very uncomfortable with changing the coding style." and "the new policy should have a historical background too. I would suggest to use 132 columns (DECwriter II)"
If we were a democracy the vote would be 120, but more African would be to reach unanimous agreement: would anyone like to comment on / veto the choice of changing the maximum permitted line width to 120 in the Osmocom projects?
~N
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Hello Neels,
As for me a maximum of 120 chars per line is perfect, more however would be problematic on my work laptop which has a 1366x768 resolution.
On a side note I've discovered Qt Creator is able to handle autotools projects, for instance this makes it very convenient to follow function calls (even across projects), or to discover who calls a particular function. It also provides a number of interesting features such as clang static analysis.
By default however the relevant plugin is disabled, and must be enabled in Help->About plugins. Then for each project the top-level Makefile.am can be opened; I also recommend to restore the session on startup (File->Sessing Manager), and setting up a shortcut to define the current project (Tools->Options->Keyboard->SetStartup).
- -cd
Dear all,
for egoistical reasons I'm in favor of a limit of 100 to 106 characters only. Otherwise I can no longer fit three terminal windows next to each other on a (these day standard minimum display width) of 1920, which would be a major step back in terms of being able to look at multiple source files simultaneously.
On Wed, Apr 05, 2017 at 04:43:09PM +0200, Harald Welte wrote:
Dear all,
for egoistical reasons I'm in favor of a limit of 100 to 106 characters only. Otherwise I can no longer fit three terminal windows next to each other on a (these day standard minimum display width) of 1920, which would be a major step back in terms of being able to look at multiple source files simultaneously.
Having the occasional bleed to a second line is not an option? I was hoping that all are fine with 120 to conclude this :)
I've gotten used to a smaller font already and now have 119 chars of line estate in my two terminals alongside. If we go for ~106 I can go back to a larger font (where the i-dot is more than a single pixel) ...
106 is a kind of odd number to pick, but it's nearer to 120 than 100. Personally, I'm fine with odd numbers for good reasons.
We could have 100 as the public "rule" to reduce the wtf-factor and use 106 as unwritten hard limit to reject patches on.
So then, asking again:
Would anyone veto/dislike an absolute max line width of 106 for all Osmocom projects?
~N
On Wed, Apr 5, 2017 at 7:43 AM, Harald Welte laforge@gnumonks.org wrote:
for egoistical reasons I'm in favor of a limit of 100 to 106 characters only. Otherwise I can no longer fit three terminal windows next to each other on a (these day standard minimum display width) of 1920, which would be a major step back in terms of being able to look at multiple source files simultaneously.
With similar considerations, my maximum is 120 characters coming from two terminal windows at display width of 1920. If one cannot fit two windows of code side-by-side at such a resolution, then readability has suffered.
-TT
Ok guys, let's go for 120 characters and have e-mails with more productive contents on this list again.
I don't think there is a problem with old code following the old line length. After all, we're not changing anything but permittedline length. It's not really evena "style" change (like whether or not to have curly braces on new lines or on the same line).
Also, general common sense applies: We do not accept patches that change the style from old to new line length. We merely write new code with longer lines, and [may] change those lines that we are editing in patches.
I'll update the wiki accordingly.
Regards, Harald
On Wed, Apr 05, 2017 at 04:43:09PM +0200, Harald Welte wrote:
Dear all,
for egoistical reasons I'm in favor of a limit of 100 to 106 characters only. Otherwise I can no longer fit three terminal windows next to each other on a (these day standard minimum display width) of 1920, which would be a major step back in terms of being able to look at multiple source files simultaneously.
If you update this, I would prefer 100 or so too.
Unless you use very long function names, the only reason that I've seen for people to go over that boundary is a symptom of low quality code.
I don't think asking for this is egoistical, it's a technical reason. Long lines are quality metric on code.
-
Alexander Chemeris -
Devine Christophe -
Harald Welte -
k＠rhizomatica.org -
Max -
Neels Hofmeyr -
Pablo Neira Ayuso -
Philipp Maier -
Sylvain Munaut -
Tom Tsou