C source code formatter: looking for a good one

[...]

IMHO, that indicates it's high time for a customer upgrade... If they want to have a comment-stripped version, but can't trust their own skill to strip the comments off the master source by themselves, so they have to ask you to provide it, odds they're in way over their heads.

Exactly. And even worse: what would make them believe that the test results of one version have anything to do with those of the other, if they can't replicate the mapping between those two?

And quoting MISRA:

A slightly strange rule IMHO, given that nested comments never existed in standard C in the first place.

This rule seems too vague to be applicable. What does 'commented out' mean (#ifdef SOMETHING / #if 0 / only /* ... */ comments)? What exactly is a "section of code" (as opposed to a normal comment block, or a line of code)? And why did they want to put one of these in quotes, but not the other?

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

[...]

IMHO, that indicates it's high time for a customer upgrade... If they want to have a comment-stripped version, but can't trust their own skills to strip the comments off the master source by themselves, so they have to ask you to provide it, odds are they're in way over their heads.

Exactly. And even worse: what would make them believe that the test results of one version have anything to do with those of the other, if they can't replicate the mapping between those two?

And quoting MISRA:

A slightly strange rule IMHO, given that nested comments never existed in standard C in the first place.

This rule seems too vague to be applicable. What does 'commented out' mean (#ifdef SOMETHING / #if 0 / only /* ... */ comments)? What exactly is a "section of code" (as opposed to a normal comment block, or a line of code)? And why did they want to put one of these in quotes, but not the other?

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

[...]

Actually, it's just redundant. Rule 1 is "ISO 9899 C only," and since ISO C doesn't allow nested comments, this is covered.

MISRA is full of little directives that are essentially "don't make this typo in your code." One of my favorites is the one (rule 85) saying that a function that takes no parameters must be called with empty parentheses. E.g. given something like

extern int ok_to_continue(void);

use this:

if (ok_to_continue() != FALSE)

and not this:

if (ok_to_continue != FALSE)

Note that rule 85 is only advisory...

Having the explanations helps sometimes. In this particular case, they are attempting to prevent accidentally nested comments, and explicitly say that using #if or #ifdef to conditionally compile a section of code is OK.

Sometimes the explanations don't help. For example, rule 29 (required) is "The use of a tag shall agree with its declaration." The full explanation given in the document is

"Where a tag has been given in the declaration of a structure, union or enumeration type, all subsequent uses of the tag shall be consistent with the declaration. For example, it would be incorrect to initialise the tag with an initialiser which did not match the structure declared for that tag. "

I *think* that means "Don't access any field of a structure that doesn't exist," but I'm not sure.

Mostly, I ignore such rules since they're impossible to break anyway.

I've said it before, but linting your code will produce far better results than blindly following any coding guideline. IMHO, and IME.

Regards,

-=Dave

--
Change is inevitable, progress is not.

FWIW, according to contributors to the safety critical mail list ( snipped-for-privacy@cs.york.ac.uk hosted out of the Univ of York,) the MISRA quidelines are in the process of a major re-write to further restrict C features that are prone to abuse, e.g., bizarre casts that compile but don't necessarilly generate reasonable/accurate results. MISRA C V2 is listed on the MISRA website as available Q1 2004.

--
Scott
Validated Software Corp.

Maybe SCO is involved? :^P

--
Ron Sharp.

already.

compiler

So add a marker in your source file after the last include statement and then just delete everything upto that marker by hand.

e.g. #include #include "myhdr.h"

char this_is_my_magic_source_code_marker;

Regards Sergio Masci

- optimising structured PIC BASIC compiler

I think there is a strong argument for wanting to strip comments out IF it is to review the code. If the code looks meaningless without comments then you are going to have serious problems. I have come across many instances where unsuitable variable names are used repeatedly or the same variable is used in many places (within the same scope) for different things. The more I think about it the more I like the idea of looking at the code without comments to see it stands up for itself. After all, the compiler does not look at the comments when validating an expression.

Regards Sergio Masci

- optimising structured PIC BASIC compiler

... snip ...

^well^

Agreed. If nothing else it may clue you in to how another modifier fouled up.

BTW the indicated usage error is very common among non-native English speakers or the poorly uneducated.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
     USE worldnet address!

Stripping out comments from source code is usually a REALLY BAD idea.

Besides, usually the problem is getting the programmers to put the comments IN.

(Hey, it usually isn't the programmer's fault. He KNOWS what that code does and how it does it, and USUALLY, if the guy reading the code doesn't understand it well enough WITHOUT comments, comments WILL NOT help him and he should NOT be trying to modify it.)

You may have a look on ArtisticStyle (found at:

it's a great source formatting toole, but i'm not sure that it's able to remove comments though.

Regards Flemming

With hopefully a word or two of explanation about what parameters are passed in and what the return value is.

How I wish more people would put just this level of commenting in their code. All to often I've worked on code where it's a battle to figure out what functions actually do.

Good code:

foo() // Read the comment- Ah foo does xyz [though the suspicious might have a // read to make sure it really does that]

Bad Code

foo() read read read - foo calls bar() bar() read read read - bar calls wibble() wibble() read read read...

and

Dear John,

I have to produce two versions of the code: one is commented and the other is clean. The one without comments will be compiled and linked to produce the executable code.

In my previous thread I said that MISRA rules state that production code should be free of comments: I'm wrong! I misinterpreted rule number 10.

thanks Enrico

comments IN.

does and

understand it

NOT be

other

Why on earth?

This policy will guarantee that after some time the commented version and the run version differ. You will have far more problems than advantages of it.

Please understand that the comments add nothing to the machine code produced, so I do not understand what is the stripped version for.

If you are forced to give the source code out and would not like, there are better methods of obfuscating the source that bare stripping of the comments. For examples, see . I strongly advise against obfuscating the code.

Tauno Voipio tauno voipio @ iki fi

IN.

and

it

be

Enrico, please, please, tell me that this is one of this "You know this is idiotic, and I know this is idiotic, but my management has given me my marching orders, and said 'And if you can't or won't do it, we will fire you and hire someone who can and will.'" Please tell me that this is what is going on.

Because this is completely idiotic.

--John

^^^^^^^^^^^^^^^^^ A double negative negating the desired meaning of a sentance is very common among non-native English speakers or the well unedutaced.

--
Trevor Barton

Sentance? unedutaced?

Are you the same guy that applied for a programming job who signed off his resume with "I am willing to lern"?

Peter

As I understood this, the uncommented version would be generated from the commented version and only the commented version would be maintained. Otherwise why bother with a tool?

Yes the comments add nothing to the executable. So perhaps at some stage it would be really useful to see the code without the comments telling you what you should be seeing. If the code looks crap without the comments then the code needs to be revised. If the comments make no difference to the understanding of the code then they are superfluous and just cluttering up the source. This would surely be a good way of telling if the comments are of a high enough nature to actually add value to the source.

I think that in the future I will insist on code reviews where uncommented code is looked at in isolation to commented code.

Regards Sergio Masci

--snip-- (hopefully preserving correct attribution (;-) --

Programming environments _do_ exist where comments affect the code size (interpreted BASIC, for example). Is there any chance that the comment-removal reuirement was originally formulated with such an environment in mind?

(...he said, desperately trying to make _some_ sense out of it (;-)).

Frank McKenney, McKenney Associates Richmond, Virginia / (804) 320-4887 Munged E-mail: frank uscore mckenney ayut minds pring dawt com (y'all)

That's *well* unedutaced. As opposed to poorly unedutaced.

--
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net