[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [paho-dev] Contributing and coding standards?
|
Seriously, I'm good with not allowing tabs, just spaces. I know that it
seems to have become a bone of contention in the last decade.
On 13/11/2018 13:57, Greg Troxel wrote:
Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx> writes:
[it feels like there is some quoting issue in the message I'm replying
to]
I can write up the coding standards I've followed. What's wrong with
tabs = 2 spaces? :-) If we did use tabs, then you could set the
indent to whatever you like when you look at it :-)
tabs really just are 8 spaces, and this is built in to many terminals.
https://en.wikipedia.org/wiki/Tab_key
In reading, I see that windows and mac editors got this wrong early on
and this perhaps has led to the confusing variable-tab notion.
Changing the meaning of ascii on a per-source-code basis is way too
prone to trouble. I realize many complicated editors can be configured,
but things like ed(1) will simply output the line as is, which will
render it according to the tab stops in the terminal (emulator, these
days), which will be 8. And things like enscript will behave similarly.
A really good rant about separating the issues:
https://www.jwz.org/doc/tabs-vs-spaces.html
I basically agree, except that I'm in the "tab stops are 8, and anything
else is broken" camp, and therefore I think it's fine to have some
numbers of tabs and some number of spaces to get to a column. But I
don't expect others to agree with that.
So if you want to use two-column indents, fine, but please either
1) leave the tab stops are every 8 convention alone, and mix tab/space
to get there, as has been the longstanding convention, or
2) ban tab characters, and indent with spaces only. This avoids the
entire "what does tab mean" discussion.
One observation I have, is that I intended the project to be easily
portable across operating systems and environments. The risk of
concentrating on one OS is that portability is lost, or hidden away.
I'd just like to be sure that isn't lost.
I agree. I maintain a lot of packages for pkgsrc, a multi-os
multi-cpu-type packaging system that in particular works on NetBSD,
MacOS, and Illumos. I think it's important to articulate standards
(POSIX, if we're talking unixy) and write to them.
For embedded, I'm not sure what the right answer is, but one candidate
is just C99, plus things as needed, keeping them minimal. One big issue
in embedded is threads; I worked on something where we specified C99 as
the interface for code we were writing and someone else was surprised
that it wasn't thread safe -- but there are no locking/thread primitives
in C99, so it couldn't be.
--
Ian Craggs
icraggs@xxxxxxxxxx IBM United Kingdom
Eclipse Paho Project Lead & Mosquitto Committer
