Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Contribution guide #7

Open
hsluoyz opened this issue Mar 6, 2020 · 5 comments
Open

Contribution guide #7

hsluoyz opened this issue Mar 6, 2020 · 5 comments
Assignees
Labels
documentation Improvements or additions to documentation

Comments

@hsluoyz
Copy link
Member

hsluoyz commented Mar 6, 2020

  1. Our build system is makefile (on Linux) & Visual Studio project files (on Windows). We don't use cross-platform building tools like CMake because I think it only makes things more complicated. Just maintaining two native build systems (makefile and Visual Studio) is easier and more friendly to users. Casbin is a library instead of app, so I must choose something used more widely. Please make your code compile well on both platforms before any PR. I personally will test the code on Visual Studio and CLion on Windows.
  2. We use Google test as the test framework.
    3. Use use namespace std;, there should be no std::string in the code. [Abandoned]
  3. The allowed source file name's extensions are .cpp and .h. Others like .cc, .hpp are forbidden.
  4. Write minimized working code first, like file adapter, model, enforcer. Don't try to setup a code framework, or something like CI, linter only. I cannot witness those things work well without concrete code.
  5. Use printf instead of cout. No cout will be allowed in the code.
  6. Follow the module (filename) naming of Golang Casbin: https://github.com/casbin/casbin . Do not invent a name by yourself.
  7. Your code in PR should compile well itself on Windows and Linux, better with tests. Do not leave a feature in half, which has 100+ compile errors and then send PR.
  8. Base your code on our latest master branch, follow our folder structure, filename naming, etc.
  9. Do not use CMake or any cross-platform building tools (I have to say it again).
  10. Don't commit so many code in one PR. One PR can only contain one commit, with 100 LoC change.
  11. Other things please follow Google C++ Style Guide: https://google.github.io/styleguide/cppguide.html
@hsluoyz hsluoyz pinned this issue Mar 6, 2020
@hsluoyz hsluoyz mentioned this issue Mar 6, 2020
@divy9881
Copy link
Member

divy9881 commented Mar 6, 2020

Will follow this conventions.

@NitinBhasneria
Copy link

@hsluoyz Thanks for this. This will be surely followed.

@zintown
Copy link

zintown commented Jun 11, 2020

Get the point,this rule will be precisely followed

@hsluoyz hsluoyz self-assigned this Jun 17, 2020
@hsluoyz hsluoyz added documentation Improvements or additions to documentation help wanted Extra attention is needed labels Jun 17, 2020
@hsluoyz hsluoyz unpinned this issue Dec 20, 2020
@PDLdeLange
Copy link
Contributor

  1. Use use namespace std;, there should be no std::string in the code.
    The problem with putting using namespace in the header files of your classes is that it forces anyone who wants to use your classes (by including your header files) to also be 'using' (i.e. seeing everything in) those other namespaces.
    However, you may feel free to put a using statement in your (private) *.cpp files.
    See also: https://stackoverflow.com/questions/1452721/why-is-using-namespace-std-considered-bad-practice

@PDLdeLange
Copy link
Contributor

Another thing to consider is adding namespaces to your project, e.g. namespace casbin { .. } in each file. This will prevent conflicts with other projects.

@hsluoyz hsluoyz removed the help wanted Extra attention is needed label Mar 30, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

5 participants