Tools for code formatting

65 views
Skip to first unread message

Joris Dauphin

unread,
Oct 31, 2013, 7:34:45 AM10/31/13
to oclin...@googlegroups.com
To standardize code (mostly spaces), we may use some tools such as:

- clang-format (since clang 3.4)

The configuration should be versionned.

Longyi Qi

unread,
Nov 14, 2013, 9:32:01 AM11/14/13
to Joris Dauphin, oclin...@googlegroups.com
Or, better than that, we could write our own rules. And that's what the implementations of `AbstractSourceCodeReaderRule` are designed for.


--
You received this message because you are subscribed to the Google Groups "OCLint Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to oclint-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Joris Dauphin

unread,
Nov 15, 2013, 8:30:05 AM11/15/13
to oclin...@googlegroups.com, Joris Dauphin
On Thursday, November 14, 2013 3:32:01 PM UTC+1, Longyi Qi wrote:
Or, better than that, we could write our own rules. And that's what the implementations of `AbstractSourceCodeReaderRule` are designed for.

With what I have in mind, I disagree:
 
I think it is useless to *duplicate* stylistic rules:
- as simple warning where these tools do fix the code by rewriting directly.
- have opposite/exclusive rules depending of chosen stylistic convention.
   For example: should I write `char* c` or `char *c` or `char * c` ?
                      use (2-4-8)spaces or tab in indentation ?
                      where to put '{' and '}' for `IfStmt` ?
- some stylistic rules need the "AST" and line source code.

I don't think it is the purpose of OCLint.

Note: I think that we may have opposite rules in oclint ('one-exit-rule' vs 'early-exit').

Longyi Qi

unread,
Nov 18, 2013, 8:39:05 AM11/18/13
to Joris Dauphin, oclin...@googlegroups.com
Hi Joris,
I agree with your opinions on reinventing the wheels that has been developed and tested by existing rules. But I won't put restrictions on OCLint's capability nor what OCLint can achieve. When we started designing the tool, we have actually thought about the `source code reader` rules, with which, we are able to write text-based stylistic rules. 

We spent the majority of the time on AST based rules, only because we - existing contributors - are more interested in this. But please be aware that, during the parsing procedure, certain information is lost, so we won't be able to get everything in AST, for example, MACROs. So, source code based rules help us preserve this level of abstraction.

You can actually get the source code from AST based rules, and you can get AST from source code based rules. We just designed different types of interfaces that make it easier to implement one type of rule, but two types of information are shared under the hook.

So, we do open the door for people who have passions in the coding standard that requires syntactic checking, and we do believe this category of rules are also beneficial to code quality. We do everything to improve code quality.

Longyi
--
Reply all
Reply to author
Forward
0 new messages