Design Con 2015
Breaking News
Newest First | Oldest First | Threaded View
<<   <   Page 2 / 2
User Rank
Re: Topic should be moot
MarkPitchford   1/22/2014 4:51:53 PM
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?  

VIntage Bits
User Rank
Re: A Real effect
VIntage Bits   1/22/2014 4:29:57 PM
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.

User Rank
Re: A Real effect
DU00000001   1/22/2014 4:21:31 PM
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
A Real effect
VIntage Bits   1/22/2014 2:23:05 PM
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.

User Rank
Re: Topic should be moot
ese002   1/22/2014 2:00:49 PM
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.

Graham Bell
User Rank
Re: Where to format
Graham Bell   1/22/2014 1:24:20 PM
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:

User Rank
Where to format
GordonScott   1/22/2014 1:03:12 PM
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.


sw guy
User Rank
Topic should be moot
sw guy   1/22/2014 10:55:41 AM
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.


<<   <   Page 2 / 2

Top Comments of the Week
Flash Poll
Like Us on Facebook 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

Feast Your Orbs on My Vetinari Clock Prototype
Max Maxfield
Well, I have to admit that I have a great big Cheshire Cat-type grin plastered on my face at the moment, because the prototype for my Vetinari Clock project is now well underway.

Jack Ganssle,

Open Office: Your Fart is My Problem
Jack Ganssle,
A Washington Post article, Google got it wrong. The open-office trend is destroying the workplace, describes how the author's ad agency moved her from a private office to an open space ...

Rich Quinnell

Bloopers Book Helps Improve GUI Development
Rich Quinnell
Courtesy of fellow editor "Max" Maxfield (aka Max the Magnificent), I recently acquired a copy of GUI Bloopers 2.0 by Jeff Johnson of UI Wizards. I found it an interesting read chock full ...

Rich Quinnell

Making the Grade in Industrial Design
Rich Quinnell
As every developer knows, there are the paper specifications for a product design, and then there are the real requirements. The paper specs are dry, bland, and rigidly numeric, making ...

Special Video Section
The LT8640 is a 42V, 5A synchronous step-down regulator ...
The LTC2000 high-speed DAC has low noise and excellent ...
How do you protect the load and ensure output continues to ...
General-purpose DACs have applications in instrumentation, ...
Linear Technology demonstrates its latest measurement ...
Demos from Maxim Integrated at Electronica 2014 show ...
Bosch CEO Stefan Finkbeiner shows off latest combo and ...
STMicroelectronics demoed this simple gesture control ...
Keysight shows you what signals lurk in real-time at 510MHz ...
TE Connectivity's clear-plastic, full-size model car shows ...
Why culture makes Linear Tech a winner.
Recently formed Architects of Modern Power consortium ...
Specially modified Corvette C7 Stingray responds to ex Indy ...
Avago’s ACPL-K30T is the first solid-state driver qualified ...
NXP launches its line of multi-gate, multifunction, ...
Doug Bailey, VP of marketing at Power Integrations, gives a ...
See how to ease software bring-up with DesignWare IP ...
DesignWare IP Prototyping Kits enable fast software ...
This video explores the LT3086, a new member of our LDO+ ...
In today’s modern electronic systems, the need for power ...