Breaking News
Comments
sw guy
User Rank
Manager
Topic should be moot
sw guy   1/22/2014 10:55:41 AM
NO RATINGS
This question shows we are still behaving like in the 80's.

With present CPUs, it should not be a problem to store source code in a style independant way and have editor apply translation to / from developper's taste.

 

GordonScott
User Rank
Manager
Where to format
GordonScott   1/22/2014 1:03:12 PM
NO RATINGS
I've generally felt that the formatting should be standardised for or by the revision management system, allowing the user to format code to their own preferred style. The RMS then 'normalises' it again on check-in.

Done using a script-wrapper or plug-in, that could likely be made to work for pretty much any language and/or style.

That would also allow the RMS to ignore many white-space differences, too.

 

Graham Bell
User Rank
Freelancer
Re: Where to format
Graham Bell   1/22/2014 1:24:20 PM
NO RATINGS
I agree with both "sw guy" and Gordon that automation tools should handle this issue today.

Like Mark Pitchford, I too was raised using a PASCAL coding style.  When we did C programming back in the day, we would use the C-preprocessor to convert PASCAL 'Begin' and 'End' statements to '{' and '}' respectively.  See more about this here: http://www.cs.cf.ac.uk/Dave/C/node14.html

ese002
User Rank
Rookie
Re: Topic should be moot
ese002   1/22/2014 2:00:49 PM
NO RATINGS
It isn't really about cpu power.  Storing code in a style independent manner means it can't be stored in plain text.  (Even if, like XML, it is based on plain text, it won't actualy be plain text)  That means that all the world's editors and other tools that process source code will be obsolete until they are updated to handle the new format. 

And that's in the best case scenerio: one format with only one version that never needs to change.  The  more realistic situation is multiple competing standardards and multiple revisions of each.

sw guy
User Rank
Manager
Re: Topic should be moot
sw guy   1/23/2014 3:56:33 AM
NO RATINGS
Of course source would in any case stored in plain plain text.

With a minimalistic formating convention.

Anyway, I now agree with GordonScott that version control system should do that, not editor. Actually, I once worked for a company where we put hooks to version control to check source file format was in accordance to coding rule. Could as well writen the hooks to perform on the fly conversion.

Even with editor performing the conversion, you would be able to use string base code inspection tool. But better with version control perforning it, as source content will be consistent whatever the tools and/or editor(s) developper uses.

MarkPitchford
User Rank
Blogger
Re: Topic should be moot
MarkPitchford   1/22/2014 4:51:53 PM
NO RATINGS
I see the point but it raises a secondary concern.

I spend a lot of my working life in the safety critical sectors, where confidence in the tools cannot be assumed. For example, for the most demanding of DO178C levels for aerospace applications, even compilers must be shown to be working in the way expected of them.

You wouldn't want to apply that to all applications; it is not commercially sensible. There is a balanced view to be taken. But you really want the end product to work no matter what the environment.

Introducing editors which manipulate and modify what you write introduces another level of possible error. Maybe the risk is tiny but it certainly exists and it seems unnecessary.

So why introduce it?  

sw guy
User Rank
Manager
Re: Topic should be moot
sw guy   1/23/2014 4:05:11 AM
NO RATINGS
I understand the concern cannot be underevaluated.

However, does such critical software developpement use source control ?

This is another tool one have to trust. I assume you do not have to trust it by deciding reference for sources is what integration (or packaging or delivery or whatever name) team got when building what is to be delivered to final customer.

Then, giving conversion task to source control instead of editor does not change anything.

I am waiting for more comments.

elizabethsimon
User Rank
CEO
Re: Topic should be moot
elizabethsimon   1/22/2014 5:04:10 PM
NO RATINGS
Assuming that the tools are readily available and easy to use to store and retrieve source code in a style independent way, that does not address ALL aspects of coding standards. There are other aspects to coding standards besides the formatting. Variable and function naming conventions are an important part of working with a team. Also things like what should be contained in a file and commenting of functions are also very important and can't be taken care of with editor translation. A good coding standard will address these issues as well.

I could also see a problem if you were working with another developer on a piece of code and viewing it on the same screen. Who gets to decide what the format should be? Much better to have consistent standards to avoid arguments.

 

VIntage Bits
User Rank
Rookie
A Real effect
VIntage Bits   1/22/2014 2:23:05 PM
NO RATINGS
I've been programming professionally for over 42 years. I found that following the Linux kernel coding standards improved my code more than any other single thing I have done. In this case, the format of the code directly leads to an easier-to-understand structure. That is, it affects the code itself.

The Linux kernel uses 8-space hard tabs and an 80-column limit. I had used 4-space tabs for years and thought it was a little crazy at first. The coding standard says that it helps produce smaller, easier-to-understand functions. After using the kernel standard for some years, I can confirm that it is true.

The Linux kernel standard does encourage developers to write smaller functions that do less and to rely on the compiler to inline things appropriately. Prior to having compilers that would do that, there was too strong a perception that functions were overhead to be avoided. Because that is usually not true any more, particularly for static functions only used in a single file, there is no reason not to write small functions. The developer does have to put a little more thought into naming functions perhaps, but that is a good thing, too.

So coding standards can have effects far beyond the aesthetic - they can have a real effect on the code itself.

DU00000001
User Rank
CEO
Re: A Real effect
DU00000001   1/22/2014 4:21:31 PM
NO RATINGS
Reading your assumptions I partly disagree:

Functions (inline functions excepted) always come hand in hand with call overhead. Inline functions come with a memory penalty. So while the Linux kernel style might be appropriate for machines where memory doesn't count, the call overhead penalty is not negligible. Whilst the performance numbers of nowadays CPUs excel what we had 20 years ago by some orders of magnitude, we're still waiting for the results of the programs. Maybe longer than then.

In my area of experience (deeply embedded systems - MCUs, not CPUs) memory and runtime still count. Thus, I ugraded my style from 4-space hard tabs interleaved with additional 2-space indentations to 4-space hard tabs 'only'. But I'm still hedging functions that do 'a little bit more' - eg. having a CAN message decoder for 7 different message layouts in a single function. So I'm having similar things within the same function - which is also good to keep the general view.

But this does not preclude having macros (the 'old-style' inline function) and/or small 'utility' functions. It's just that you need all of them to get things up and running within limited time.

VIntage Bits
User Rank
Rookie
Re: A Real effect
VIntage Bits   1/22/2014 4:29:57 PM
NO RATINGS
Actually, there is no memory penalty for a static inline function, because if it is static and all calls within that function were inlined and nothing takes the address of the function, then the function itself will not be emitted. If you omit the keyword static, then the function wil unconditionally be emitted. The Linux coding standards require using static for functions used solely within a single file for that reason and also to reduce global namespace pollution.

elizabethsimon
User Rank
CEO
Re: A Real effect
elizabethsimon   1/22/2014 5:11:22 PM
NO RATINGS
I think this just shows that a case can be made for different standards if needed to "drive" the development in one directin or another but certainly within a project or within a company there should be a standard so everyone can work together on a team.

Of course if you are the only one doing development then you get to set the standards...

Alvie
User Rank
Blogger
Yes, it does.
Alvie   1/23/2014 3:28:51 PM
NO RATINGS
A bit late of a reply...


I work for a software company, and we have quite some strict rules for our software development, and that does include code conventions, but not limited to. Our focus is in safety-critical systems, and as such we have clients that do require some standards to be applied (DO-179B, ISO26262, others). In the beginning, we followed those as per clients requirement, but soon we decided to incorporate guidelines in our own internal processes.

First, let me make very clear that coding conventions are not about the overall layout of the code (the given example is not a good example of what the coding conventions are about). They exist so that the product (as source code) can be tested, maintained, and in a more general approach, allow for a concrete mapping between it (the code), the design, and the requirements.

Let's go for some examples. The first one is a classic (and forbidden by the standard MISRA rules):
if (bSomethingWickedHappened) {
    /* Loop like mad, expect a reset soon */
    while (1) {
    }
}

Why is this code bad ? It is an infinite loop, but it cannot be tested. MISRA forbids infinite loops, but they do happen, but the main problem here is not the infinite loop itself, the problem is that you cannot ensure that you actually entered the while loop. The instrumentation tools (like LDRA) will indeed place an instrumentation call inside the while loop, but, unless you have a fancy way to go back so to report that, you're basically doomed - the code will just, well, loop. (Mark will understand this).

So, the right way to "code" that piece of block is to allow you to redefine the clause, like this:
if (bSomethingWickedHappened) {<
    /* Loop like mad, expect a reset soon */
    while (TRUE) {
    }
}

This way, you can redefine TRUE in such a way (stub) that you can indeed get out of that loop, and report your findings.


And let's take a look at another example, different one (yes, I have seen this code):

if (aux1==1 && aux2==3 && aux4!=0) {

myFunc(aux4,9);

}

Let's rewrite this according to the rules:

if (bFirstTimeCalled==TRUE && uNumberOfAccounts==3 && pClientStruct!=NULL) {

vAddCreditsToClient(pClientStruct, 9);

}

Which one do you understand ?

Most standard do not actually impose a standard on you, but they impose that a standard shall be used, one that helps your code to be scrutinized and proved right, without the need to use formal methods.

Conventions impose some overhead, but it pays off.

Just ask the new guy that came to fix a bug. He knows.

Alvie

MarkPitchford
User Rank
Blogger
Re: Yes, it does.
MarkPitchford   1/23/2014 3:45:24 PM
NO RATINGS
As you say, your comments expand the discussion beyond style; for example, as you point out most (if not all) MISRA rules & guidelines are not about style at all.

However, no law against that! in essence I agree with everything you've said, particularly the last comment.

After all, we've all been that guy who has had to fix the bug....

DMcCunney
User Rank
CEO
It does If multiple programmers will work on the code
DMcCunney   1/23/2014 4:18:24 PM
NO RATINGS
@Mark Pitchford:  As long as it exists, then, the detail of programming style doesn't matter at all. It is the consistency of style that is all important.

Precisely. The best comment I recall on the topic was in a document on coding in TCL, where a particular style was mandated.  The comment was essentially "It's not whether this style is "better", it's that we all do it the same way."

Most programming is done by teams.  You aren't the only one who will ever look at and perhaps modify your code.  If the style you prefer is different from that used by others, you introduce friction into the process.  Style matters because it affects readability and therefore code comprehension.  If the project has standards for style all follow, friction is reduced.  It doesn't take all that long to get used to a particular style, and your editor may well have facilities to enforce that style as you code.


And in any case, if you're writing code for money, you do it the way the people paying you want it done.

elizabethsimon
User Rank
CEO
Re: It does If multiple programmers will work on the code
elizabethsimon   1/23/2014 4:44:20 PM
NO RATINGS
@DMcCunney

And in any case, if you're writing code for money, you do it the way the people paying you want it done.

Exactly. And if you don't like it, you find another job.

 

Matt S.
User Rank
Rookie
Many styles
Matt S.   1/23/2014 8:14:22 PM
NO RATINGS
When I learned "C", everything I learned from was 1TBS (one true brace) (author's first example.)  Wikipedia has an excellent summary of the variety of styles in their "Indent Style" article, it's certainly worth a visit, and discusses all the various styles with the origins of each.  

The style that most directly contradicts 1TB is the WhiteSmith style (see the wikipedia article!) which makes it very difficult for a 1TB familiar to "see" when editing a WhiteSmith styled source - whereas for one who uses the Allman style (author's second example), it's more easy to adjust to the indented braces.

Anyhow, some sophisticated editors (e.g. SlickEdit) can "beautify" the code automatically to a style the editor supports - though the tab spacing can be an issue.  

http://en.wikipedia.org/wiki/Indent_style

As for myself, I use 1TBS, because I like to have as much "code" on the screen at one time, rather than needing to scroll up and down just to get past all the braces.

 

Charles.Desassure
User Rank
Manager
Yes..
Charles.Desassure   1/24/2014 10:55:01 AM
NO RATINGS
I worked as a programmer in my early career.   It was very important that everyone on the programming team program in the same style.   Why?  (1) It allowed us as a team to serve our clients much better  (2)  It allowed us as a team  to update/change program request quickly  (3) It allowed us as a team to use our department programming style to train new employees  (4) Time.   Of course, I can go on and on; but programming in the same style is a must from my point-of-view if you are working within collaboration environment.



Flash Poll
Top Comments of the Week
Like Us on Facebook
EE Times on Twitter
EE Times Twitter Feed

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)
EE Life
Frankenstein's Fix, Teardowns, Sideshows, Design Contests, Reader Content & More
Max Maxfield

Vetinari Clock: Decisions, Decisions, Decisions …
Max Maxfield
37 comments
Things are bouncing merrily along with regard to my uber-cool Vetinari Clock project. The wooden cabinet is being handcrafted by my chum Bob (a master carpenter) using an amazing ...

Jolt Judges and Andrew Binstock

Jolt Awards: The Best Books
Jolt Judges and Andrew Binstock
1 Comment
As we do every year, Dr. Dobb's recognizes the best books of the last 12 months via the Jolt Awards -- our cycle of product awards given out every two months in each of six categories. No ...

Engineering Investigations

Air Conditioner Falls From Window, Still Works
Engineering Investigations
2 comments
It's autumn in New England. The leaves are turning to red, orange, and gold, my roses are in their second bloom, and it's time to remove the air conditioner from the window. On September ...

David Blaza

The Other Tesla
David Blaza
5 comments
I find myself going to Kickstarter and Indiegogo on a regular basis these days because they have become real innovation marketplaces. As far as I'm concerned, this is where a lot of cool ...