Re: [paho-dev] Contributing and coding standards?

[Daniel Santos <daniel.santos@xxxxxxxxx>]

Thank you for your input Greg!

I used to be very picky about what I thought was wrong and right in code
formatting, but working in the FOSS world as taught me that the style
its self doesn't matter as much as the consistency of it's use.  Having
said that...





On 11/13/2018 07:57 AM, 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.

For C libraries it's probably appropriate to assume non-thread-safe
unless otherwise specified.  So I guess this also hints at the need for
sufficient documentation, perhaps at the @file level to clarify little
things like that.

As far as everything else multi-OSy/archy, this is definitely part of
what I want to consider, but there should still be room in there for
some consistency across implementations (file naming conventions, header
locations, etc.).

Daniel