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

Feature - 2910 Add coding guidelines #559

Merged
merged 19 commits into from Jan 21, 2016
Merged

Conversation

Poltergeist
Copy link
Contributor

For now these rules are open for discussion.

This PR introduces new eslint settings which are only warnings for now until all issues are resolved then these warnings are switched to errors.

This closes mesosphere/marathon#2910

Rules:
- Indentation is done with 2 spaces in most cases.
- Line breaks are only done if needed, try to use the 80 character limit.
- Strings are splitted at the latest possible position.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

split

@pierluigi
Copy link
Contributor

@Poltergeist Thanks a ton for taking care of this. Really appreciated.

## JSDoc
If there is a return there should be a type and description.
If there is one or multiple parameter/s there should be a name, type and description for each one.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would add, that the function should be understandable without commenting, so it actually needs no comment header. A function should be descriptive by reading the code or the function definition itself.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the code itself needs commenting then you probably did something wrong.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would compare the JSDoc description to a cover text of a book you should not need to read it to understand the contents but if you scan it you know something about the contents before reading it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Think about the function-naming and the parameters as the cover text. :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What I find useful is to document a whole file with a meaningful description on the top, but not single functions.

@aldipower
Copy link
Contributor

This is already very complete! Great! Good work so far. The really important things are all covered. It's a good doc that can be complemented later, if needed.

Some things I think about, that should be documented, are:

  • let in and after block-scopes.
  • In general we prefer a more functional coding style. .forEach() preferred instead of a for-loop.
  • If you don't know how to style the code and can't find it here, look at the AirBnB styles. A lot is derived from there!
  • Functions and code must be self-descriptive. Use function doc-headers only if really necessary.
  • Usage of template-strings
  • CSS coding styles
  • Sort alphabetically
  • How to indent chained functions like promises or map/reduce-functions.
  • Use named function if they are in "private" scope.

- Indentation is 2 spaces.
- No multiple empty lines.

We prefer a functional approach and try to use the abstractions over
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds perfect to me. Thanx!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor:
try to use the_se_ abstractions

```

## JSDoc
JSDoc blocks should be avoided in favor to code descriptiveness. If the are necessary these rules apply:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍
Little typo (maybe mine ;) ):
If the_y_

@Poltergeist Poltergeist changed the title [WIP] Feature - 2910 Add coding guidelines Feature - 2910 Add coding guidelines Jan 20, 2016
@aldipower
Copy link
Contributor

Let's merge this! :)

This was a lot of work @Poltergeist , good job, thanx!

Most things are covered!
The guideline can/should be extended/complemented at every time.

aldipower added a commit that referenced this pull request Jan 21, 2016
@aldipower aldipower merged commit 6562872 into master Jan 21, 2016
@aldipower aldipower deleted the feature/add-coding-guidelines branch January 21, 2016 10:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants