Bug #34312
openmgr/dashboard: Style guide for frontend/Angular coding conventions
0%
Description
Let's start the discussion about coding conventions as it seems we don't have at least the following topic covered yet or no clear coding conventions at all. Please feel free to add topics to be discussed here as well as your opinion on the topic mentioned below.
I have noticed that the models seems to be everywhere in the code (which might make sense, but I don't know if it makes sense). There's a central shared location for models and there are models in module and component directories. The models have very different names. Some indicate that they are models by having a `.model.` string in their name, others don't. This together makes it hard to find particular models or even get a list of available/existing models to be reviewed or used.
I personally feel that, if it makes sense to have models basically everywhere, we should at least stick to a naming convention so that they can easily be found. `.model.` feels natural to me as components and services follow this convention, too. What are your thoughts about that and other topics?
Updated by Stephan Müller over 5 years ago
I have a view topics that aren't covered.
File / Method lengths?
INHO less than 500 lines per file which raises the question where to split it up and how to (should be explained to).
Method less than 20 lines.
Should Methods be allowed to contain newlines?
IMHO they should not.
Updated by Patrick Seidensal over 5 years ago
Another topic which came up recently is the underscore prefix for private methods. I've seen it in a pull request and suggested to completely not use it anymore for various reasons (which I didn't mention) and because the Angular Style Guide says "don't do that" (which I did mention).
Updated by Patrick Seidensal over 5 years ago
- Subject changed from mgr/dashboard: Style guide for frontend/Angualar coding conventions to mgr/dashboard: Style guide for frontend/Angular coding conventions
Updated by Patrick Seidensal over 5 years ago
I forgot to mention that I would generally like to stick to the Angular Style Guide and only add rules where we think its required (project specific additions). I think project specific exceptions should be rare but we might want or need them, too.
Updated by Patrick Seidensal over 5 years ago
codelyzer might be helpful as it is compatible with Angular and extends tslint rules to match pre-defined rules of the Angular Style Guide.
Updated by Lenz Grimmer over 5 years ago
Note that Ceph has a dedicated CodingStyle document that already has a section about JavaScript / TypeScript - this is the document that should be updated with any additional conventions that we agreed to.
Updated by Lenz Grimmer over 5 years ago
Patrick Nawracay wrote:
I forgot to mention that I would generally like to stick to the Angular Style Guide and only add rules where we think its required (project specific additions). I think project specific exceptions should be rare but we might want or need them, too.
FYI: the aforementioned Coding Style document already states that we follow the official Angular Style Guide.
Updated by Lenz Grimmer about 5 years ago
- Related to Feature #27218: mgr/dashboard: Style guide to give a the UI an overall look and feel added
Updated by Lenz Grimmer about 5 years ago
- Related to Feature #34530: mgr/dashboard: CdSubmitButton should be disabled if the form was not modified added
Updated by Lenz Grimmer about 5 years ago
- Related to Cleanup #35683: mgr/dashboard: Refactoring of Modal Dialogs added
Updated by Ernesto Puerta almost 4 years ago
Reviewed and decided to keep it open
Updated by Ernesto Puerta about 3 years ago
- Project changed from mgr to Dashboard
- Category changed from 132 to General