Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] Contributing and coding standards?

Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx> writes:

[it feels like there is some quoting issue in the message I'm replying

> 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.
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:

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.

Back to the top