It would be great to have an automatic tool able to show variables that appear one time only, declared constants never used, procedures never call, ressources not used (includes, etc.)
When you've done a lot of test and correction in codes, this kind of help would really help before creating a real executable.
Code Cleaner tool
- langinagel
- Enthusiast
- Posts: 131
- Joined: Fri Jan 28, 2005 11:53 pm
- Location: Germany
- Contact:
Re: Code Cleaner tool
Agree,
some kind of a lint program would be fine for Purebasic - either inside the compiler or extern.
But this would require to define some common coding rules before:
Some MISRA rules for example:
Sections of code should not be "commented out";
Identifiers in an inner scope shall not use the same name as an identifier in an outer scope, and therefore hide that identifier;
No identifier name should be reused;
Orphan variables shall not be used;
Dead code shall not be used;
just one procedurereturn per procedure.
A discussion, what ruleset is applicable for Purebasic, should be started.
some kind of a lint program would be fine for Purebasic - either inside the compiler or extern.
But this would require to define some common coding rules before:
Some MISRA rules for example:
Sections of code should not be "commented out";
Identifiers in an inner scope shall not use the same name as an identifier in an outer scope, and therefore hide that identifier;
No identifier name should be reused;
Orphan variables shall not be used;
Dead code shall not be used;
just one procedurereturn per procedure.
A discussion, what ruleset is applicable for Purebasic, should be started.
Re: Code Cleaner tool
I totally agree with you
- langinagel
- Enthusiast
- Posts: 131
- Joined: Fri Jan 28, 2005 11:53 pm
- Location: Germany
- Contact:
Re: Code Cleaner tool
Well , fine. let us start the discussion.
Here.
What kind of rules should be checked?
Sections of code should not be "commented out";
- this could be checked by just uncommenting and trying to compile.
Identifiers in an inner scope shall not use the same name as an identifier in an outer scope, and therefore hide that identifier;
- so...here the question with name spaces and modules could be raised: different module: same name allowed?
Mark problems with one-letter variables: i, j, k, ?
No identifier name should be reused;
- again : ok in the same module thus namespace. Different module ?
Orphan variables shall not be used;
- How to define orphan? No contributrion to result in procedure? Difficult! No change in procedure? ..maybe...
Dead code shall not be used;
- what is about defensive programming? Any consequent default-usage will lead to code that usually will never be reached. Unsafe programming?
just one procedurereturn per procedure.
- OK
More rules to be applied?
Comments to my comments? Keep on, it's a thread.
Cheers
LN
Here.
What kind of rules should be checked?
Sections of code should not be "commented out";
- this could be checked by just uncommenting and trying to compile.
Identifiers in an inner scope shall not use the same name as an identifier in an outer scope, and therefore hide that identifier;
- so...here the question with name spaces and modules could be raised: different module: same name allowed?
Mark problems with one-letter variables: i, j, k, ?
No identifier name should be reused;
- again : ok in the same module thus namespace. Different module ?
Orphan variables shall not be used;
- How to define orphan? No contributrion to result in procedure? Difficult! No change in procedure? ..maybe...
Dead code shall not be used;
- what is about defensive programming? Any consequent default-usage will lead to code that usually will never be reached. Unsafe programming?
just one procedurereturn per procedure.
- OK
More rules to be applied?
Comments to my comments? Keep on, it's a thread.
Cheers
LN
Re: Code Cleaner tool
Some code review/format tool would be very good to make sources less chaotic, but currently can't say anything about exact criteria.
"W̷i̷s̷h̷i̷n̷g o̷n a s̷t̷a̷r"
- langinagel
- Enthusiast
- Posts: 131
- Joined: Fri Jan 28, 2005 11:53 pm
- Location: Germany
- Contact:
Re: Code Cleaner tool
Sorry to say...but code review is the opposite direction.
Code review is also a static code check but can only be done by human eyes looking over the code and checking for:
-remaining compliance to style guide
-remaining compliance to coding rules
-requirements fulfillment
-fulfillment of software design requirements
Please be aware of the "remaining": this means that a Code Cleaner Tool - as intended in this thread - is available and was applied before code review.
Just every rule that the tool is not able to find must be checked by human eyes.
Any contributions to checkable rules (that are worth to be checked)?
One thing: "enableexplicite" at the beginning of each code file, no "disableexplicit" in whole file. Agree?
LN
Code review is also a static code check but can only be done by human eyes looking over the code and checking for:
-remaining compliance to style guide
-remaining compliance to coding rules
-requirements fulfillment
-fulfillment of software design requirements
Please be aware of the "remaining": this means that a Code Cleaner Tool - as intended in this thread - is available and was applied before code review.
Just every rule that the tool is not able to find must be checked by human eyes.
Any contributions to checkable rules (that are worth to be checked)?
One thing: "enableexplicite" at the beginning of each code file, no "disableexplicit" in whole file. Agree?
LN
Re: Code Cleaner tool
I wasn't speaking of a big tool : often, we need to start with a low level of correction... so I would to sort 3 kind of rules !
1) Speed and memory optimisation
- show unused variables, unused procedures...
- show open IO (network, console, file) without close
- empty loop (for t=1 to 1000 : next t)
- empty condition (if xxxx else (nothing) endif
- ...
2) Normalize code
- Each variables should be declared first (like using enableexplicit)
- Local variables (in procedure) should be static or protected (if not global)
- ...
3) Hard Core rules
- ...
The first level would be enough for me because I just need to help beginners
1) Speed and memory optimisation
- show unused variables, unused procedures...
- show open IO (network, console, file) without close
- empty loop (for t=1 to 1000 : next t)
- empty condition (if xxxx else (nothing) endif
- ...
2) Normalize code
- Each variables should be declared first (like using enableexplicit)
- Local variables (in procedure) should be static or protected (if not global)
- ...
3) Hard Core rules
- ...
The first level would be enough for me because I just need to help beginners

- langinagel
- Enthusiast
- Posts: 131
- Joined: Fri Jan 28, 2005 11:53 pm
- Location: Germany
- Contact:
Re: Code Cleaner tool
It took me some time to think about your answer.
Still from my amateur point-of-view I see a few contradictions to "...wasn't speaking of a big tool":
-speed and memory optimisation: maybe possible by the noted cases, but why not show a hint to the programmer? Maybe he just has forgotten some LoC. To found such cases there is a few "intelligence" necessary in the code of the code cleaner.
-normalize code: ...why not check code for existing enableexplicite? Other solutions would be complex, thus some kind of a contradiction.
- any hard core rule might be complex for checking.
I think you rather begin with using "enableexplicite" in all your codes.
And about the tool: maybe check the code of lint or splint. These are not very big tools, but the code for the tools is not done overnight.
Others who are interested in such a PB-Lint tool and its based coding rules: don't hesitate to contact me for discussion.
Cheers
LN
Still from my amateur point-of-view I see a few contradictions to "...wasn't speaking of a big tool":
-speed and memory optimisation: maybe possible by the noted cases, but why not show a hint to the programmer? Maybe he just has forgotten some LoC. To found such cases there is a few "intelligence" necessary in the code of the code cleaner.
-normalize code: ...why not check code for existing enableexplicite? Other solutions would be complex, thus some kind of a contradiction.
- any hard core rule might be complex for checking.
I think you rather begin with using "enableexplicite" in all your codes.
And about the tool: maybe check the code of lint or splint. These are not very big tools, but the code for the tools is not done overnight.
Others who are interested in such a PB-Lint tool and its based coding rules: don't hesitate to contact me for discussion.
Cheers
LN