1 Apr
2017
1 Apr
'17
11:45 a.m.
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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
1 Apr
1 Apr
12:30 p.m.
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/
2:43 p.m.
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
2:54 p.m.
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(a)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(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================
================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch.
A6)
10:25 a.m.
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?
--
Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
10:35 a.m.
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
--
Philipp Maier<pmaier(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
10:39 a.m.
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,
--
Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
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.
2:03 p.m.
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
2:34 p.m.
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_…
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
5 Apr
5 Apr
2:43 p.m.
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
4:23 p.m.
-----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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJY5P3kAAoJECrKWTqY+zzatB4H/iR7Fy4TFB28yQDgpwp/rgVf
4Z41rzzH9gwlLbsEtKSVOWygLULpsZ0xXUlJw/x59I5u3xQIPEk3d6eP6s3v5XNM
DmaX/grTksKhNfOBtE2UDCh3SjPbUU5eDxsYocEhCvJxt3Rmd3MzCKBHfgumR9Ev
/jBhKiSRyi/T4yO14sKEYiRivQ48x7cECsvI0O6xnQ9mqx0/HhRy9XtaQfz7sg9z
tmbmgyJWTgyJaNsACJyQTiE9J7DZRyVKCVnhHRBisGroTT8I8G/pLV44NQqDlubv
ouZ/KjB88s67KWjjPOQWIUi2KC9du3JjUHk9yMfTRtsGks+E/oBymqOQuhD3eE4=
=lbux
-----END PGP SIGNATURE-----
4:43 p.m.
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.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
6:26 p.m.
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
7:59 p.m.
On Wed, Apr 5, 2017 at 7:43 AM, Harald Welte <laforge(a)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
8:54 p.m.
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
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
6 Apr
6 Apr
5:35 p.m.
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.
2587
days inactive
2592
days old
16 comments
10 participants
participants (10)
-
Alexander Chemeris -
Devine Christophe -
Harald Welte -
k＠rhizomatica.org -
Max -
Neels Hofmeyr -
Pablo Neira Ayuso -
Philipp Maier -
Sylvain Munaut -
Tom Tsou