-
Notifications
You must be signed in to change notification settings - Fork 180
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Updates Content/Chapter-10-methods/methods-naming-good-practices/meth…
…ods-naming-good-practices.md Auto commit by GitBook Editor
- Loading branch information
Svetlin Nakov
committed
Jan 24, 2019
1 parent
2ed582b
commit 084de45
Showing
9 changed files
with
85 additions
and
98 deletions.
There are no files selected for viewing
4 changes: 2 additions & 2 deletions
4
...pter-1-first-steps-in-programming/exercises-first-steps-in-coding/expression.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
2 changes: 1 addition & 1 deletion
2
...first-steps-in-programming/exercises-first-steps-in-coding/triangle-of-stars.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
2 changes: 1 addition & 1 deletion
2
...ramming/exercises-graphical-and-web-apps/sumator-graphical/sumator-graphical.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
2 changes: 1 addition & 1 deletion
2
...teps-in-programming/exercises-graphical-and-web-apps/sumator-web/sumator-web.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
71 changes: 0 additions & 71 deletions
71
...apter-10-methods/methods-naming-good-practices/methods-naming-good-practices.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,71 +0,0 @@ | ||
| # Naming Methods and Good Practices for Using Methods | ||
|
|
||
| In this part we will show you some **established practices** when working with methods, connected with the naming, the arrangement and the structure of the code. | ||
|
|
||
| ## Naming Methods | ||
|
|
||
| When you name a method it is good to use **meaningful names**. Because every method **answers** for a part of our problem, when naming it we should keep in mind **the action it does**, i.e. it is a good practice for **the name to describe what the method does**. | ||
|
|
||
| The name must start with **uppercase** and should be made of a verb or a couple: verb + noun. The name is formatted by following the **Upper Case Camel** convention, i.e. **each word, including the first, starts with uppercase**. The brackets **`( `** and **`)`** always follow the name. | ||
|
|
||
| Each method must do one task and its name should describe what its function is. | ||
|
|
||
| A few examples for **correctly** naming our methods: | ||
| * **`FindStudent`** | ||
| * **`LoadReport`** | ||
| * **`Sine`** | ||
|
|
||
| A few examples for **incorrectly** naming our methods: | ||
| * **`Method1`** | ||
| * **`DoSomething`** | ||
| * **`HandleStuff`** | ||
| * **`SampleMethod`** | ||
| * **`DirtyHack`** | ||
|
|
||
| If you can not think of a good name then the method most probably solves more than one task or doesn't have a clearly defined purpose and in this case you have to think how to divide it in several simpler methods. | ||
|
|
||
| ## Naming Method Parameters | ||
|
|
||
| When naming **the parameters** of a method you can apply almost the same rules as with the methods themselves. The difference here is that it is good for the names of the parameters to use a noun or a couple of an adjective and a noun, and when naming the parameters we use the **`lowerCamelCase`** convention, i.e. **each word except for the first one starts with uppercase**. We should note that it is good practice that the name of the parameter **shows** what **unit**is used when working with it. | ||
|
|
||
| A few examples for **correctly** named parameters: | ||
| * **`firstName`** | ||
| * **`report`** | ||
| * **`speedKmH`** | ||
| * **`usersList`** | ||
| * **`fontSizeInPixels`** | ||
| * **`font`** | ||
|
|
||
| A few examples for **incorrectly** named parameters: | ||
| * **`p`** | ||
| * **`p1`** | ||
| * **`p2`** | ||
| * **`populate`** | ||
| * **`LastName`** | ||
| * **`last_name`** | ||
|
|
||
| ## Good Practices When Working with Methods | ||
|
|
||
| Let us remind you that a method should do **only one** defined **task**. If this can not be done you must think how to **divide** the method into a few, smaller ones. As we already said the name of the method should be clear and should describe its purpose. Another good practice in programming is to **avoid** methods, which are longer than our screen (approximately). If the code still becomes large it is recommended to **divide** it into several, shorter methods, as in the example below. | ||
|
|
||
|  | ||
|
|
||
| ## Code Structure and Formatting | ||
|
|
||
| When writing methods we should be careful to do correct **indentation** (moving blocks of the code to the right). | ||
|
|
||
| Example for **correctly** formatted C# code: | ||
|
|
||
|  | ||
|
|
||
| Example for **incorrectly** formatted C# code: | ||
|
|
||
|  | ||
|
|
||
| When the title line of the method is **too long**, it is recommended to divide it into several lines, as each line after the first is two tabulations to the right of the first (for better readability): | ||
|
|
||
|  | ||
|
|
||
| Another good practice when writing code is **to leave an empty row** between the methods, after loops and conditional statements. Also try to **abstain** from writing **long lines and complicated expressions**. In time you will see that this makes the readability better and saves time. | ||
|
|
||
| It is also recommended to always **use curly brackets for the bodies of conditional statements and loops**. The brackets not only improve readability, but also reduce the possibility to make a mistake and the program to run incorrectly. | ||
41 changes: 41 additions & 0 deletions
41
Content/Chapter-10-methods/what-method-is/method-naming.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,41 @@ | ||
| # Naming Methods | ||
|
|
||
| When you name a method it is good to use **meaningful names**. Because every method **answers** for a part of our problem, when naming it we should keep in mind **the action it does**, i.e. it is a good practice for **the name to describe what the method does**. | ||
|
|
||
| The name must start with **uppercase** and should be made of a verb or a couple: verb + noun. The name is formatted by following the **Upper Case Camel** convention, i.e. **each word, including the first, starts with uppercase**. The brackets **`( `** and **`)`** always follow the name. | ||
|
|
||
| Each method must do one task and its name should describe what its function is. | ||
|
|
||
| A few examples for **correctly** naming our methods: | ||
| * **`FindStudent`** | ||
| * **`LoadReport`** | ||
| * **`Sine`** | ||
|
|
||
| A few examples for **incorrectly** naming our methods: | ||
| * **`Method1`** | ||
| * **`DoSomething`** | ||
| * **`HandleStuff`** | ||
| * **`SampleMethod`** | ||
| * **`DirtyHack`** | ||
|
|
||
| If you can not think of a good name then the method most probably solves more than one task or doesn't have a clearly defined purpose and in this case you have to think how to divide it in several simpler methods. | ||
|
|
||
| ## Naming Method Parameters | ||
|
|
||
| When naming **the parameters** of a method you can apply almost the same rules as with the methods themselves. The difference here is that it is good for the names of the parameters to use a noun or a couple of an adjective and a noun, and when naming the parameters we use the **`lowerCamelCase`** convention, i.e. **each word except for the first one starts with uppercase**. We should note that it is good practice that the name of the parameter **shows** what **unit**is used when working with it. | ||
|
|
||
| A few examples for **correctly** named parameters: | ||
| * **`firstName`** | ||
| * **`report`** | ||
| * **`speedKmH`** | ||
| * **`usersList`** | ||
| * **`fontSizeInPixels`** | ||
| * **`font`** | ||
|
|
||
| A few examples for **incorrectly** named parameters: | ||
| * **`p`** | ||
| * **`p1`** | ||
| * **`p2`** | ||
| * **`populate`** | ||
| * **`LastName`** | ||
| * **`last_name`** |
25 changes: 25 additions & 0 deletions
25
Content/Chapter-10-methods/what-method-is/methods-best-practices.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,25 @@ | ||
| # Good Practices When Working with Methods | ||
|
|
||
| Let us remind you that a method should do **only one** defined **task**. If this can not be done you must think how to **divide** the method into a few, smaller ones. As we already said the name of the method should be clear and should describe its purpose. Another good practice in programming is to **avoid** methods, which are longer than our screen (approximately). If the code still becomes large it is recommended to **divide** it into several, shorter methods, as in the example below. | ||
|
|
||
|  | ||
|
|
||
| ## Code Structure and Formatting | ||
|
|
||
| When writing methods we should be careful to do correct **indentation** (moving blocks of the code to the right). | ||
|
|
||
| Example for **correctly** formatted C# code: | ||
|
|
||
|  | ||
|
|
||
| Example for **incorrectly** formatted C# code: | ||
|
|
||
|  | ||
|
|
||
| When the title line of the method is **too long**, it is recommended to divide it into several lines, as each line after the first is two tabulations to the right of the first (for better readability): | ||
|
|
||
|  | ||
|
|
||
| Another good practice when writing code is **to leave an empty row** between the methods, after loops and conditional statements. Also try to **abstain** from writing **long lines and complicated expressions**. In time you will see that this makes the readability better and saves time. | ||
|
|
||
| It is also recommended to always **use curly brackets for the bodies of conditional statements and loops**. The brackets not only improve readability, but also reduce the possibility to make a mistake and the program to run incorrectly. |
2 changes: 1 addition & 1 deletion
2
Content/Chapter-2-1-simple-calculations/graphical-apps/graphical-apps.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters