Paul A. Bristow wrote:

...

-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On

Behalf Of

...

Mateusz Loskot Sent: Saturday, January 02, 2010 9:48 PM To: boost@lists.boost.org Subject: Re: [boost] coding conventions

Michael wrote:

...

hi all,

here's a first patch:

it was generated using the command 'svn diff > ../boost.diff"

questions on the formatting of new code (conforming standards used at gdb-patches@gnu.org):

1) can lines exceed the 80 character limit?

With the widespread use of wider screens, some Boost authors are already edging beyond 80 char width.

...

http://www.boost.org/development/requirements.html#Guidelines

Perhaps we should relax the 80 char width recommendation? (and anyway it is only a recommendation? - Readability comes first?)

Paul

PS Using 2 space indentation reduces the risk of running over the 80 width, so is my preference.

--- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow@hetp.u-net.com

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Hi, While we now hopefully agree on the coding guidelines, I had hoped you don't mind me having a quick look at the ublas input/output the upcoming few days. Regards, Michael

Hi Stefan, Thanks for answering, it appears that you can answer my mails while the original doesn't appear in my personal inbox. Anyone who can help me on this? Also, I suppose I should contact the people at ublas@lists.boost.org then. Thanks. Michael. Stefan Strasser wrote:

Am Sunday 03 January 2010 12:23:04 schrieb Michael:

...

Hi,

While we now hopefully agree on the coding guidelines, I had hoped you don't mind me having a quick look at the ublas input/output the upcoming few days.

I think it is boost practice to ask the library author to apply a patch. posting it to the mailing list if the library author disagrees with the changes doesn't do any good. (imho your use of {} makes the code less readable.) _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On Mon, Jan 4, 2010 at 7:27 AM, Stewart, Robert <Robert.Stewart@sig.com> wrote:

...

PS Using 2 space indentation reduces the risk of running over the 80 width, so is my preference.

Some find two too small to visually align vertically, but four limits indentation depth, so we've used three for years.  (Gasp!  Yes, three isn't a power or multiple of two, but it works well.)

I have always been curious about that. To me it makes *no* sense to use spaces for indentation. I always use tabs for indentation and spaces for alignment, my reasoning is that you can set tabs to be any size you want in your editor, one space if you wish even, and spaces for alignment just makes sense, for example: class myClass : public anotherClass { public: float f_; myClass(std::string s // assume we need to wrap due to being too long ,float f) // aligned with spaces after being tabbed equal to the above line :anotherClass(s) // indented with tabs ,f_(f) { // do stuff, two tabs } } And I have just always done it that way, therefore if I view it in my IDE (with 4-space tabs) it looks perfect, if I need to view it in crappy windows notepad (with 8-space tabs), it still looks perfect, and I can yet open it in another thing and set the tabs to 1-space to make it easier to print, and I can compress and grow it as I wish, I tend to prefer 4-space tabs for editing since it lets me eyes easily follow scopes and such without taking too much space.

On Mon, Jan 4, 2010 at 4:09 PM, OvermindDL1 <overminddl1@gmail.com> wrote:

And of course the email client converted my tabs to 8 spaces, but you get the idea...

I liked this paper about tabs/spaces: http://www.jwz.org/doc/tabs-vs-spaces.html /$

Rob Riggs wrote:

I personally prefer 4 spaces, but that is more a compromise with the additional block levels in C++ compared with C (namespace, class, method).

I wouldn't recommend indenting things within namespaces, unless the content is very short. Certain libraries have 4 levels of namespace nesting.

On Tue, Jan 5, 2010 at 8:27 AM, Paul A. Bristow <pbristow@hetp.u-net.com> wrote:

...

-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Mathias Gaunard Sent: Monday, January 04, 2010 7:52 PM To: boost@lists.boost.org Subject: Re: [boost] coding conventions

Rob Riggs wrote:

...

I personally prefer 4 spaces, but that is more a compromise with the additional block levels in C++ compared with C (namespace, class, method).

I wouldn't recommend indenting things within namespaces, unless the content is very short.

Certain libraries have 4 levels of namespace nesting.

Ah well yes - an argument for 2 space indents ;-)

Paul

PS Help! - moderators needed to prevent this becoming a bike shed issue?

I think it is clear we can't get a consensus.

As the Irishman said when asked directions "I wouldn't start from here."

If tabs had been used throughout, we could have let users decide their own indent, but we missed that opportunity, for what seemed like good reasons at the time.

So we have to muddle along not really pleasing anyone, but not making anyone *terminally* unhappy.

There are things we can run on the source that reformats it all to proper guidelines, including setting tabs, moving braces where necessary, so forth, could always use one of those over the entire Boost library.

On 6 Jan 2010, at 00:52, OvermindDL1 wrote:

There are things we can run on the source that reformats it all to proper guidelines, including setting tabs, moving braces where necessary, so forth, could always use one of those over the entire Boost library.

The biggest problem with such tools is that they break diffing, so they would break the connection between release and trunk, between version before and after the reformat, and also break any patches any users keep (I myself keep a few patches on my local version which usually apply without problem to the next version, but I'm sure wouldn't apply after such a reformat). I would also be shocked if any such tool worked well on the complex C++ code stored in boost. I have not been a tool which formats my own C++ code well, as most tools work by simple regexps, whereas C++ requires much more context. Chris

An excellent paper and one that influenced my use of tabs/spaces. I also like the rationale for 8 spaces per indent level here: http://www.chris-lott.org/resources/cstyle/LinuxKernelCodingStyle.txt

I personally prefer 4 spaces, but that is more a compromise with the additional block levels in C++ compared with C (namespace, class, method). Hey, who knew Linus agreed with me on everything but 4 vs 8, and the

Rob Riggs wrote: main reason I like 4 is for reading other peoples brain-damaged code. LOL! Patrick

Mathias Gaunard wrote:

Patrick Horgan wrote:

...

Hey, who knew Linus agreed with me on everything but 4 vs 8

If you agreed on everything with Linus but the size of indentation, you wouldn't be interested in Boost, nor in C++ at all. You made me laugh out loud. I meant in that one document!!!

Patrick

OvermindDL1 wrote:

I have always been curious about that. To me it makes *no* sense to use spaces for indentation. I always use tabs for indentation and spaces for alignment, my reasoning is that you can set tabs to be any size you want in your editor, one space if you wish even, and spaces for alignment just makes sense, for example:

If code is written with two-column tab stops and viewed with eight-column tab stops, the code can easily exceed the display or printed page width. With spaces, the original author's indentation is preserved, so the line lengths can't exceed 80 columns (presuming the original was so constrained) regardless of the width of a tab stop. OTOH, I understand that using tabs for indentation does allow each person to view a file as preferred without affecting other's view of the same file (ignoring line length problems, of course). As was noted by Daniel James, for Boost at least the issue is moot. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

Am Monday 04 January 2010 16:58:49 schrieb Jonathan Franklin:

On Mon, Jan 4, 2010 at 8:08 AM, OvermindDL1 <overminddl1@gmail.com> wrote:

...

I have always been curious about that.  To me it makes *no* sense to use spaces for indentation.  I always use tabs for indentation and spaces for alignment, my reasoning is that you can set tabs to be any size you want in your editor, ...

Turns out, I want my tabs to be 8 characters, and my code indentation at 2. And my favorite color happens to be blue. ;-)

hey, if you need something to do, the final documentation of a proposed library has been posted here two days ago. not do interrupt your important discussion, after all tabs and spaces is what boost is famous for... =)

Stewart, Robert wrote:

Paul A. Bristow wrote:

...

Mateusz Loskot wrote:

... elision by patrick... Perhaps we should relax the 80 char width recommendation? (and anyway it is only a recommendation? - Readability comes first?)

I constrain my code to 80 columns and have no problems with readability, though I can imagine those used to long lines might. Long lines are quite difficult to read in my preferred editor configuration. A highly subjective criteria like readability is troublesome as justification for relaxing the width restriction.

And it doesn't make any sense. Books constrain themselves to about 60 columns because much more than that and readability suffers. I understand and share the frustration of having to break lines up, but I can tell you from my own experience, (and I'm sure I'm not unusual in this), that reading code with long lines takes a lot longer to figure out and understand, even when I make my screen wide enough. There's something about having all the information in one field of view that works for human beings. There's been a lot of usability research to back this up.

Using proportional fonts increases the opportunity for text to exceed a given screen width depending upon the viewer's selected font. One person using a small or tight proportional font and a high screen resolution or large screen will easily exceed the screen width of another person using a looser or larger font or a screen with lower resolution or smaller width. Using 80 columns as the limit ensures that regardless of the font, it will fit on any developer's screen and the printed page without wrapping or truncation.

I happen to like arranging two buffers (file views) side-by-side in a single window and often have two such windows up at once (dual monitors). That allows me to have as many as four 80-column files visible at once. There are other configurations and not everyone does what I do, but the point of the Guidelines is "Boost's widely distributed source code should follow more conservative guidelines."

I do the same, great for cut and paste, or for looking at a header and a source file.

...

PS Using 2 space indentation reduces the risk of running over the 80 width, so is my preference.

Some find two too small to visually align vertically, but four limits indentation depth, so we've used three for years. (Gasp! Yes, three isn't a power or multiple of two, but it works well.)

I like four for source, but oddly two for lilypond source. (And as a strange aside, though I thought I'd morphed quite a bit over the years, a recent re-reading of an ancient copy of K&R pointed out that I'd STRONGLY imprinted on their style. My code still looks just like theirs! LOL!) Patrick

Beman Dawes wrote:

Filesystem.V3 uses 90 characters as the normal width, and I'm planning to gradually move all of my code to 90.

That's hardly in keeping with the advice in http://www.boost.org/development/requirements.html#Design_and_Programming. It may not be a hard rule, but wouldn't it be better to get consensus on changing the guideline before doing so? Incidentally, why 90 columns? Is that just to annoy those that rely on 80 columns for readability? ;-) Seriously, it seems such an arbitrary number that I'm left to wonder why. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

Jeff Flinn wrote:

Stewart, Robert wrote:

Of course we should stick with the FORTRAN driven 80 character limit for and eschew any advancements in computer technology for eternity. ;-)

I can come up with arguments for longer character limits based on good graphic design and presentation practices. Why not 90?

Read the archives of this thread and others over the years. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

...

...

...

...

"Rob" == Stewart, Robert <Robert.Stewart@sig.com> writes:

Rob> Incidentally, why 90 columns? Is that just to annoy those that Rob> rely on 80 columns for readability? ;-) Seriously, it seems Rob> such an arbitrary number that I'm left to wonder why. Let me saying upfront that I don't particularly care what width boost uses. In my own code I tend to use lines longer than 80 characters (sometimes even much longer). I just find that declarations of templates can be more logically organized if certain things are on one line. In particular this happens to me for proto grammars. The rest of my code gravitates towards the 80 character limit, but given the occasional long lines described above I don't sweat if they are 85 characters. This until I need to print listings (I occasionally want to study/debug my code away from a computer). Then I curse very long lines. I pretty much have to print in landscape orientation that has the problem of limiting the amount of vertical context. 90 characters seems to be about the limit if you want to print portrait with a legible font. But for boost, really, I don't care. There're other (semi) stylistic things that would be more important. For instance following the bcp/namespace thread I started looking at boost code and there're way more than one way to do include guards. This coupled with the fact that some headers are supposed to be included more than once (but this fact is not documented, as far as I can tell) makes harder than needed to write bcp like tools. Maurizio

Emil Dotchevski wrote:

What are we going to do with developers who exceed the 80 or 90 character length in their source code? Fire a warning shot, and if they don't fix it, shoot to kill? :)

So you are one of those people soft on coding convention mockers?!!! Why would there be a warning shot? LOL! Patrick