@@ -623,28 +623,28 @@ function combine(val1, val2) {
623
623
** [ ⬆ back to top] ( #table-of-contents ) **
624
624
625
625
## ** Objects and Data Structures**
626
- ### Use getters and setters
626
+ ### Use getters and setters
627
627
JavaScript doesn't have interfaces or types so it is very hard to enforce this
628
628
pattern, because we don't have keywords like ` public ` and ` private ` . As it is,
629
629
using getters and setters to access data on objects if far better than simply
630
630
looking for a property on an object. "Why?" you might ask. Well, here's an
631
631
unorganized list of reasons why:
632
632
633
- 1 . When you want to do more beyond getting an object property, you don't have
633
+ 1 . When you want to do more beyond getting an object property, you don't have
634
634
to look up and change every accessor in your codebase.
635
- 2 . Makes adding validation simple when doing a ` set ` .
635
+ 2 . Makes adding validation simple when doing a ` set ` .
636
636
3 . Encapsulates the internal representation.
637
- 4 . Easy to add logging and error handling when getting and setting.
637
+ 4 . Easy to add logging and error handling when getting and setting.
638
638
5 . Inheriting this class, you can override default functionality.
639
- 6 . You can lazy load your object's properties, let's say getting it from a
640
- server.
639
+ 6 . You can lazy load your object's properties, let's say getting it from a
640
+ server.
641
641
642
642
643
643
** Bad:**
644
644
``` javascript
645
645
class BankAccount {
646
646
constructor () {
647
- this .balance = 1000 ;
647
+ this .balance = 1000 ;
648
648
}
649
649
}
650
650
@@ -657,7 +657,7 @@ bankAccount.balance = bankAccount.balance - 100;
657
657
``` javascript
658
658
class BankAccount {
659
659
constructor () {
660
- this .balance = 1000 ;
660
+ this .balance = 1000 ;
661
661
}
662
662
663
663
// It doesn't have to be prefixed with `get` or `set` to be a getter/setter
@@ -692,7 +692,7 @@ class UserSettings {
692
692
constructor (user ) {
693
693
this .user = user;
694
694
}
695
-
695
+
696
696
changeSettings (settings ) {
697
697
if (this .verifyCredentials (user)) {
698
698
// ...
@@ -723,7 +723,7 @@ class UserSettings {
723
723
this .user = user;
724
724
this .auth = new UserAuth (user)
725
725
}
726
-
726
+
727
727
changeSettings (settings ) {
728
728
if (this .auth .verifyCredentials ()) {
729
729
// ...
@@ -972,6 +972,13 @@ async function getCleanCodeArticle() {
972
972
973
973
974
974
## ** Formatting**
975
+ Formatting is subjective. Like many rules herein, there is no hard and fast
976
+ rule that you must follow. The main point is DO NOT ARGUE over formatting.
977
+ There are [ tons of tools] ( http://standardjs.com/rules.html ) to automate this.
978
+ Use one! For things that don't fall under the purview of automatic formatting
979
+ (indentation, tabs vs. spaces, double vs. single quotes, etc.) look here
980
+ for some guidance.
981
+
975
982
### Use consistent capitalization
976
983
JavaScript is untyped, so capitalization tells you a lot about your variables,
977
984
functions, etc. These rules are subjective, so your team can choose whatever
@@ -1009,6 +1016,91 @@ class Alpaca {}
1009
1016
** [ ⬆ back to top] ( #table-of-contents ) **
1010
1017
1011
1018
1019
+ ### Function callers and callees should be close
1020
+ If a function calls another, keep those functions vertically close in the source
1021
+ file. Ideally, keep the caller right above the callee. We tend to read code from
1022
+ top-to-bottom, like a newspaper. Because of this, make your code read that way.
1023
+
1024
+ ** Bad:**
1025
+ ``` javascript
1026
+ class PerformanceReview {
1027
+ constructor (employee ) {
1028
+ this .employee = employee;
1029
+ }
1030
+
1031
+ lookupPeers () {
1032
+ return db .lookup (this .employee , ' peers' );
1033
+ }
1034
+
1035
+ lookupMananger () {
1036
+ return db .lookup (this .employee , ' manager' );
1037
+ }
1038
+
1039
+ getPeerReviews () {
1040
+ let peers = this .lookupPeers ();
1041
+ // ...
1042
+ }
1043
+
1044
+ perfReview () {
1045
+ getPeerReviews ();
1046
+ getManagerReview ();
1047
+ getSelfReview ();
1048
+ }
1049
+
1050
+ getManagerReview () {
1051
+ let manager = this .lookupManager ();
1052
+ }
1053
+
1054
+ getSelfReview () {
1055
+ // ...
1056
+ }
1057
+ }
1058
+
1059
+ let review = new PerformanceReview (user);
1060
+ review .perfReview ();
1061
+ ```
1062
+
1063
+ ** Good** :
1064
+ ``` javascript
1065
+ class PerformanceReview {
1066
+ constructor (employee ) {
1067
+ this .employee = employee;
1068
+ }
1069
+
1070
+ perfReview () {
1071
+ getPeerReviews ();
1072
+ getManagerReview ();
1073
+ getSelfReview ();
1074
+ }
1075
+
1076
+ getPeerReviews () {
1077
+ let peers = this .lookupPeers ();
1078
+ // ...
1079
+ }
1080
+
1081
+ lookupPeers () {
1082
+ return db .lookup (this .employee , ' peers' );
1083
+ }
1084
+
1085
+ getManagerReview () {
1086
+ let manager = this .lookupManager ();
1087
+ }
1088
+
1089
+ lookupMananger () {
1090
+ return db .lookup (this .employee , ' manager' );
1091
+ }
1092
+
1093
+ getSelfReview () {
1094
+ // ...
1095
+ }
1096
+ }
1097
+
1098
+ let review = new PerformanceReview (employee);
1099
+ review .perfReview ();
1100
+ ```
1101
+
1102
+ ** [ ⬆ back to top] ( #table-of-contents ) **
1103
+
1012
1104
## ** Comments**
1013
1105
### Only comment things that have business logic complexity.
1014
1106
Comments are an apology, not a requirement. Good code * mostly* documents itself.
0 commit comments