search

ssvlab / dsverifier

DSVerifier - Digital Systems Verifier
http://dsverifier.org
Apache License 2.0
10 stars 4 forks source link

Design Patterns: CPPLint #71

Open feliperodri opened 7 years ago

feliperodri commented 7 years ago

Dear colleagues,

I've uploaded the cpplint.py script to our utils/design patterns/. The next step will be to apply it to all .cpp files in the DSVerifier project.

I've applied it to the script to run our experiments for JSCP and I've implemented almost all issues, but those:

  1. Class or struct identifier should end with t, not _t [readability/identifiers] [4] (I always use _t, is it really necessary to change it?)

  2. Lines should be <= 80 characters long [whitespace/line_length] [2] (Could we use at least a 100 characters long?)

  3. ifndef header guard has wrong style, please use: CPROVER_PTS_JSCP2017_DSVERIFIER_METRICS_COLLECTOR_T_H [build/header_guard] [5] (I have no ideia why is getting CPROVER_PTS)

  4. Do not use namespaces [readability/namespace] [4] (Why can't we use namespaces?)

lucasccordeiro commented 7 years ago

@feliperodri: What is the current status of this task?

feliperodri commented 7 years ago

@lucasccordeiro this task is on hold. I and @lennonchaves will work on it after we finish the JSCP paper about DSVerifier 2.0.

feliperodri commented 7 years ago

CODING_STANDARD.txt

There are a few things that we (@lucasccordeiro, @lennonchaves, and @hussamaa) need to consider:

  1. Are all unit tests running successfully? (I believe Traves CI is taking care of that)
  2. Is the source code well-formatted and clean? (Are we gonna use CPPLINT or the standard in attached?)
  3. Is there a testing procedure for each implemented function? (Does anyone know an easy way to test it automatically?)
  4. Is the source code well-documented? (How can we evaluate this?)
lucasccordeiro commented 7 years ago
  1. Expect so.
  2. No, we have to improve the code. Yes, you can use cpplint.
  3. No. It would be nice to create unit tests using CUnit (https://sourceforge.net/projects/cunit/) for every implemented function.
  4. No. It would be nice to document it with doxygen.
hussamaa commented 7 years ago

Hi @feliperodri,

Firstly, congratulation on your movement.

Lines should be <= 80 characters long [whitespace/line_length] [2] (Could we use at least a 100 characters long?)

Are you using only cpplint rules? or following a coding style? For instance, there is one from Google for C/C++. In particular, I would recommend you to download the coding rules and set it on eclipse (if it is the DSVerifier default environment). So, you don't need to count all lines, and the plugin will take care of these details.

Is the source code well-documented? (How can we evaluate this?)

Well, you can use a tool called Sonar, which provides a static analysis of the code and has a nice web interface, that shows % of the code commented, coverage(?), cpplint issues, bugs, and etc. However, I am not sure how to set it up for C/C++ ... I think it is worth to have a look at this tool.

Something to keep in mind ... I would replace our make file and scripts written in shell script by Gradle (groovy). Despite, Gradle is heavier than make, it can offers us some flexibility with respect to the environment, UTs, and etc.

Best, Hussama Ismail

lucasccordeiro commented 7 years ago

@feliperodri: May I ask you for the current status of this issue?