Please enable JavaScript.
Coggle requires JavaScript to display documents.
Best practices & coding styles, Block indentation: +2 spaces - Coggle…
Best practices & coding styles
programming style :
Source file
Structure
1/Start with License or copyright
2/Pacakge statement
3/Import statements
3.1/All static imports in a single block
3.1/All non-static imports in a single block
Must have
exactly one line
separates each section.
4/Exactly
one
top-level class
Code Smell
:forbidden:
Code Organization
Don't Say, “I’ll fix it later”
Don't Convince yourself that styling issues are not that important
Don't use names that don’t add any information to the function or identifier
Teamwork
Working on your own all the time
Abandoning plans too early
Refusing to write bad code
Not sharing with your team what you’ve learned
Not using Google enough
Not getting help when you're stuck
Testing and maintenance
Writing tests to pass
WRITING CODE
Using the wrong tool for the job
Not bothering with mastering your tools and IDE
PROGRAMMING BEST PRACTICES FOR WRITING BETTER CODE
code should be :
-maintainable,
robust,
-verifiable,
readable
Test-Driven Development (TDD) Test driven development basically it is writing a test so that we have a documentation we ca relay on and we can verify our code
introduces a user for the code that will be written.
Pure Functions
Best practises for software development
YAGNI
Fail fast:
Code is the enemy
Tests dont need testing
Coding conventions
Reduction of complexity
Refactoring:
refers to a software maintenance activity where source code is modified to improve readability or improve its structure
Comment conventions
Indent style conventions:
Tabs, spaces, and size of blocks
Naming conventions:
Readability
Letter case and numerals
Block indentation: +2 spaces
Formatting
Braces
Empty blocks: may be concise
An empty block or block-like construct may be in K & R style. Alternatively, it may be closed immediately after it is opened, with no characters or line break in between ({}), unless it is part of a multi-block statement (one that directly contains multiple blocks: if/else or try/catch/finally).
Braces are used where optional
Braces are used with if, else, for, do and while statements, even when the body is empty or contains only a single statement.
Braces follow the Kernighan and Ritchie style ("Egyptian brackets") for
nonempty blocks and block-like constructs
: No line break before the opening brace. Line break after the opening brace. Line break before the closing brace. Line break after the closing brace, only if that brace terminates a statement or terminates the body of a method, constructor, or named class. For example, there is no line break after the brace if it is followed by else or a comma.
One statement per line
Column limit: 100
Line-wrapping
Indent continuation lines at least +4 spaces
Where to break
Whitespace
Vertical Whitespace
Horizontal Whitespace
Horizontal alignment: never required
Specific constructs
Enum classes
After each comma that follows an enum constant, a line break is optional. Additional blank lines (usually just one) are also allowed.
text
Each time a new block or block-like construct is opened, the indent increases by two spaces. When the block ends, the indent returns to the previous indent level. The indent level applies to both code and comments throughout the block.