Ερωτηση για στυλ κωδικα

[AllCowsEatGrass]

Γιατι προφανές; Το μισώ προσωπικά.

 

 

Right-thinking people know that ( a ) K&R are _right_ and ( b ) K&R are right.

 

Sorry, you lose

[migf1]

Δεν υπάρχει προφανές και μη προφανές για τη θέση των braces (αν αυτό εννοείτε με το "bracers") δηλαδή των άγκιστρων. Είναι καθαρά θέμα προτίμησης ή συμφωνίας (π.χ. τα Allman, GNU και Whitesmiths coding styles που μου έρχονται πρόχειρα στο μυαλό τώρα, προτείνουν το άνοιγμα του άγκιστρου στην από κάτω γραμμή).

 

Σχετικά με την αρχική ερώτηση, ένα πλεονέκτημα του τρόπου που προτιμώ εγώ όταν είμαι ελεύθερος να επιλέξω (και που παρέθεσα στο προηγούμενο ποστ), είναι πως μου επιτρέπει πολύ εύκολα & γρήγορα να προσθέτω νέους όρους στη συνθήκη (ακόμα και με copy & paste γραμμής ή γραμμών από άλλα σημεία του κώδικα) ή να τους αφαιρώ, επειδή βάζω στην από κάτω γραμμή και το κλείσιμο της παρένθεσης της συνθήκης.

[Portmaster]

typo, braces!

Ναι είναι θέμα προτίμησης όντως, απλά την συγκεκριμένη προτίμηση την έχουν εκφράσει οι creators της C καθώς και όλοι όσοι "θαυμάζω" και γενικά συγκλίνω στις απόψεις τους.

[migf1]

Δεν πρέπει όμως να ξεχνάμε πως όταν βγήκε η C, ο "κόσμος των υπολογιστών" ήταν ακόμα text-based (και γενικώς αρκετά απλοποιημένος συγκριτικά με το σήμερα) με αποτέλεσμα οι κώδικες που γράφαμε τότε να ήταν πολύ πιο μαζεμένοι από τους σημερινούς.

 

Ειδικά όταν γράφουμε κώδικα για GUI, ή όταν υιοθετούμε αντικειμενοστραφείς πρακτικές στον κώδικά μας, είναι αρκετά δύσκολο να διατηρήσουμε αρκετές από τις προτάσεις των Kernighan & Ritchie, λόγω του μεγάλου μήκους των ονομασιών (κυρίως στις συναρτήσεις αλλά ενίοτε και στις μεταβλητές).

 

Για παράδειγμα, όταν σήμερα γράφουμε GTK+ κώδικα, ή παλαιότερα Win32 κώδικα, τα... "μακρινάρια" είναι αρκετά συχνά  αναπόφευκτα. Δηλαδή όταν έχουμε συναρτήσεις με ονομασίες όπως gtk_adjustment_get_page_increment() ή GetWindowTextLength() και αντίστοιχες ονομασίες macros, κλπ, είναι κάπως δύσκολο να ανοίγουμε τα άγκιστρα στην ίδια γραμμή και ταυτόχρονα να παραμένουμε πίσω από την 79η στήλη του editor, όπως προτείνουν οι K&R.

 

Πάντως εγώ πολύ συχνά χρησιμοποιώ συνδυασμό από διάφορα coding styles, και ας είναι εις βάρος της ομοιογένειας. Για παράδειγμα, όταν έχω μικρά μπλοκς συνήθως ανοίγω τα άγκιστρα στην ίδια γραμμή, αλλά όταν έχω μεγάλα μπλοκς τα ανοίγω από κάτω. Επίσης, όταν έχω π.χ. 2 φωλιασμένα for και το σώμα του μέσα for έχει ένα μικρό if, συνήθως στο βαθύτερο μπλοκ (if) ανοίγω το άγκιστρο στη ίδια γραμμή, αλλά στα παραπάνω επίπεδα (τα 2 for) το ανοίγω στην από κάτω. Αν το μέσα if είναι μεγάλο ως μπλοκ, τότε ανοίγω και σε αυτό το άγκιστρο στην από κάτω γραμμή.

 

ΥΓ. Γενικώς τα προτιμώ μαζεμένα τα πράγματα, αλλά πολύ συχνά είναι έως κι αδύνατον να το συμβιβάσουμε με τα διάφορα API που χρησιμοποιούμε.

[ZAKKWYLDE]

Το ενδιαφέρον είναι ότι παρ'όλο που οι Κ&R προτείνουν το δικό τους στύλ, η πλειοψηφία του κώδικα που βλέπω σε C είναι Allman style. Ευτυχώς βέβαια που το πρότειναν οι K&R γιατί όποτε γράφω C με αυτό το στυλ και με κράζουν έχω καλή δικαιολογία . Στη Java συγκεκριμένα πάντως το K&R style είναι convention και καλό είναι να ακολουθείται.

[defacer]

Καταρχήν δεδομένου ότι το statement είναι μικρότερο από 80 columns δεν θα πρέπει να σπάσει καθόλου, δεύτερον και προφανές τα bracers στο ίδιο line...

 

[...]

Γράφω 99% C#, σε πολύ σπάνιες περιπτώσεις να χρησιμοποιήσω ενα lambda variable (func) απο πάνω για να κάνω wrap το expression εαν είναι αρκετά complex.

 

80 columns: εκτός κι αν υπάρχουν ιδιαίτερες συνθήκες (π.χ. team members που δουλεύουν visual studio σε laptop) νομίζω πως αυτό είναι κατάλοιπο μιας άλλης εποχής. Σε οποιοδήποτε σύστημα με μια όχι προπολεμική οθόνη κι ένα καλό editor πας τουλάχιστον μέχρι τα 120. Τι νόημα έχει να έχουμε όλο αυτό τον οριζόντιο χώρο (ειδικά στις 16:9) και να μη τον χρησιμοποιούμε;

 

Όσο για το lambda, στην προκειμένη περίπτωση νομίζω πως θα ήταν πολύ καλύτερα απλά να γίνει ένα private method. Εφόσον δεν το χρησιμοποιείς σαν μεταβλητή μόνο αρνητικά βλέπω σ' αυτή την επιλογή, μου φέρνει στο μυαλό κατάσταση χρησιμοποιώ πάντα το καινούριο όχι γιατί είναι καλύτερο αλλά γιατί είναι καινούριο.

 

Τέλος μιλώντας για C# αν δεν υπάρχει βάσιμη αντίρρηση νομίζω πως είναι χρήσιμο να ακολουθεί κανείς τους default κανόνες του StyleCop, μιας και έτσι κι αλλιώς τρέχουμε StyleCop στο codebase για να είμαστε σίγουροι ότι δεν τράβηξε ένας για Χίο κι άλλος για Μυτιλήνη.

[Mika]

80 columns: εκτός κι αν υπάρχουν ιδιαίτερες συνθήκες (π.χ. team members που δουλεύουν visual studio σε laptop) νομίζω πως αυτό είναι κατάλοιπο μιας άλλης εποχής. Σε οποιοδήποτε σύστημα με μια όχι προπολεμική οθόνη κι ένα καλό editor πας τουλάχιστον μέχρι τα 120. Τι νόημα έχει να έχουμε όλο αυτό τον οριζόντιο χώρο (ειδικά στις 16:9) και να μη τον χρησιμοποιούμε;

 

 

+ απειρο. 

[defacer]

Να συμπληρώσω πως όταν λέω 120 δεν εννοώ να τις γεμίζουμε με if (a.foo < bar && (widget.frob() || !--x)) έτσι; Σ' αυτές τις περιπτώσεις, method και βαφτίζεις τη συνθήκη. Απλά μερικές φορές μπορεί να έχεις ένα απλό expression το οποίο έχει μεγάλους σε μήκος identifiers κλπ.

[ZAKKWYLDE]

80 columns: εκτός κι αν υπάρχουν ιδιαίτερες συνθήκες (π.χ. team members που δουλεύουν visual studio σε laptop) νομίζω πως αυτό είναι κατάλοιπο μιας άλλης εποχής. Σε οποιοδήποτε σύστημα με μια όχι προπολεμική οθόνη κι ένα καλό editor πας τουλάχιστον μέχρι τα 120. Τι νόημα έχει να έχουμε όλο αυτό τον οριζόντιο χώρο (ειδικά στις 16:9) και να μη τον χρησιμοποιούμε;

 

Προσωπικά σε 1920 πλάτος βρίσκω ότι με 80 chars με φτάνει ίσα ίσα για να έχω στο Eclipse 2 tabs με κώδικα + κάποιο στενό tab με code/project outline. Εντάξει όλα αυτά φυσικά είναι θέματα προσωπικής προτίμησης. 

[defacer]

Προσωπικά σε 1920 πλάτος βρίσκω ότι με 80 chars με φτάνει ίσα ίσα για να έχω στο Eclipse 2 tabs με κώδικα + κάποιο στενό tab με code/project outline. Εντάξει όλα αυτά φυσικά είναι θέματα προσωπικής προτίμησης. 

 

Ε ναι. Αλλά εννοείς δύο tabs side by side? Σε κάποιες περιπτώσεις το έχω κάνει και γω (αν και πλέον απλά ξεκολλάω το δεύτερο tab και το πετάω -- ή και τα δύο, αν χρειαστεί -- στη δεύτερη οθόνη) αλλά επί μονίμου βάσεως?

[ZAKKWYLDE]

Ε ναι. Αλλά εννοείς δύο tabs side by side? Σε κάποιες περιπτώσεις το έχω κάνει και γω (αν και πλέον απλά ξεκολλάω το δεύτερο tab και το πετάω -- ή και τα δύο, αν χρειαστεί -- στη δεύτερη οθόνη) αλλά επί μονίμου βάσεως?

 

Ναι side by side εννοώ. Το κάνω συνήθως γιατί στο ένα έχω το frontend (.xhtml) και στο άλλο το backing class. H κάποιες φορές έχω και το ίδιο αρχείο σε διαφορετικά σημεία. Στην δεύτερη οθόνη συνήθως έχω τον Browser ή το Console αναλόγως + κάποιο reference κώδικα. Όταν πάρω 3η οθόνη θα είναι καλύτερα πάντως

[defacer]

Όταν πάρω 3η οθόνη θα είναι καλύτερα πάντως

 

Amen to that... αν και νομίζω πως καλύτερα θα είναι 2x27" σε QHD ή μεγαλύτερη ανάλυση, ανάλογα πού θα έχει πάει η τεχνολογία. Mε 2x23" προσωπικά τσίμα τσίμα τη βγάζω με πολύ μικρές κινήσεις του λαιμού, με τρεις φαντάζομαι θα ζαλίζεσαι από το πολύ δεξιά-αριστερά.

[Portmaster]

80 columns: εκτός κι αν υπάρχουν ιδιαίτερες συνθήκες (π.χ. team members που δουλεύουν visual studio σε laptop) νομίζω πως αυτό είναι κατάλοιπο μιας άλλης εποχής. Σε οποιοδήποτε σύστημα με μια όχι προπολεμική οθόνη κι ένα καλό editor πας τουλάχιστον μέχρι τα 120. Τι νόημα έχει να έχουμε όλο αυτό τον οριζόντιο χώρο (ειδικά στις 16:9) και να μη τον χρησιμοποιούμε;

 

Όσο για το lambda, στην προκειμένη περίπτωση νομίζω πως θα ήταν πολύ καλύτερα απλά να γίνει ένα private method. Εφόσον δεν το χρησιμοποιείς σαν μεταβλητή μόνο αρνητικά βλέπω σ' αυτή την επιλογή, μου φέρνει στο μυαλό κατάσταση χρησιμοποιώ πάντα το καινούριο όχι γιατί είναι καλύτερο αλλά γιατί είναι καινούριο.

 

Τέλος μιλώντας για C# αν δεν υπάρχει βάσιμη αντίρρηση νομίζω πως είναι χρήσιμο να ακολουθεί κανείς τους default κανόνες του StyleCop, μιας και έτσι κι αλλιώς τρέχουμε StyleCop στο codebase για να είμαστε σίγουροι ότι δεν τράβηξε ένας για Χίο κι άλλος για Μυτιλήνη.

Δεν είναι τόσο απλά τα πράγματα, η πλειοψηφία των open source projects παίζουν με 80 columns οπότε αναγκαστικά αν κάνεις contributions / διαβάζεις κώδικα etc το συνηθίζεις. Δεν μπαίνω στον κόπο να έχω άλλο format στην δουλειά, ειδικά όταν κάτι το έχει συνηθίσει το μάτι μου. Επίσης solution explorer + 2 tabs με merge / diff ότι οθόνη και να έχεις εκεί κοντά στα 80 columns είναι ιδανικό να έχεις όλη την εικόνα.

 

Όσο για Laptop, έχω ένα rMBP με πάνελ 2880 x 1800 αλλά φυσικό μέγεθος 1440 x 900 λόγω dpi scaling (200%). Πάλι τα 80 columns είναι κοντά στο ιδανικό.

 

Για το lambda ούτε εγώ τρελαίνομαι αλλά το καλό (γενικά με τα lambdas) είναι ότι δεν χρειάζεται να ανατρέξω στο definition του function, είναι ακριβώς από πάνω. Με το peek definition στο VS13 έχει κάπως λυθεί και αυτό.

 

Δεν είμαι πολύ fan του style στον κώδικα της MS, κυρίως ίσως διότι μέχρι πρόσφατα σχετικά δεν υπήρχαν και πολλά open source projects τους να δω. Πλέον με το asp.net stack που υπάρχει αρκετός κατέληξα στο ότι δεν με τρελαίνει, 120 columns και braces σε new line. Αυτό που είδα και υιοθέτησα είναι τα using statements μέσα στο namespace.

[defacer]

Δεν είναι τόσο απλά τα πράγματα, η πλειοψηφία των open source projects παίζουν με 80 columns οπότε αναγκαστικά αν κάνεις contributions / διαβάζεις κώδικα etc το συνηθίζεις. Δεν μπαίνω στον κόπο να έχω άλλο format στην δουλειά, ειδικά όταν κάτι το έχει συνηθίσει το μάτι μου. Επίσης solution explorer + 2 tabs με merge / diff ότι οθόνη και να έχεις εκεί κοντά στα 80 columns είναι ιδανικό να έχεις όλη την εικόνα.

 

Όσο για Laptop, έχω ένα rMBP με πάνελ 2880 x 1800 αλλά φυσικό μέγεθος 1440 x 900 λόγω dpi scaling (200%). Πάλι τα 80 columns είναι κοντά στο ιδανικό.

 

Για το lambda ούτε εγώ τρελαίνομαι αλλά το καλό (γενικά με τα lambdas) είναι ότι δεν χρειάζεται να ανατρέξω στο definition του function, είναι ακριβώς από πάνω. Με το peek definition στο VS13 έχει κάπως λυθεί και αυτό.

 

Δεν είμαι πολύ fan του style στον κώδικα της MS, κυρίως ίσως διότι μέχρι πρόσφατα σχετικά δεν υπήρχαν και πολλά open source projects τους να δω. Πλέον με το asp.net stack που υπάρχει αρκετός κατέληξα στο ότι δεν με τρελαίνει, 120 columns και braces σε new line. Αυτό που είδα και υιοθέτησα είναι τα using statements μέσα στο namespace.

 

Σίγουρα, όταν μιλάμε για teams δε μπορείς να αποφασίσεις μόνος σου. Προσωπικά πάντως μπαίνω στον κόπο (δε θεωρώ πως είναι κόπος, σχήμα λόγου φαντάζομαι) να έχω άλλο format όπου μπορώ, εξάλλου δεν είναι και πάντα στο χέρι σου -- αν π.χ. έχεις δύο διαφορετικά code bases στη δουλειά με διαφορετικά style τότε μπαίνεις στον κόπο θες δε θες. Κι αν δουλεύεις open source ακόμα πιθανότερο. Έτσι κι αλλιώς όλα τα σοβαρά IDE υποστηρίζουν per-project code style οπότε δεν υπάρχει πρακτικό εμπόδιο.

 

Σχετικά με το lambda, και με την επιφύλαξη ότι σε μια τέτοια συζήτηση σίγουρα περνάμε στον άλλο μόνο ένα ελάχιστο ποσοστό απ' αυτά που έχουμε στο μυαλό μας: νομίζω πως στη γενική περίπτωση αν χρειάζεται να δεις το definition για να καταλάβεις τι γίνεται στο call site, you are doing it wrong. Επίσης, βάζοντάς τον κώδικα για μια method μέσα σε μια άλλη (αυτό κάνεις στην ουσία) καταφανώς παραβιάζεται το single responsibility principle και πρακτικά αν το αφήσεις unchecked καταλήγεις να έχεις monster methods με όλα τα προβλήματα που αυτό συνεπάγεται.

 

Σχετικό: http://programmers.stackexchange.com/questions/184037/descriptive-naming-vs-80-character-lines

[Portmaster]

Σίγουρα, όταν μιλάμε για teams δε μπορείς να αποφασίσεις μόνος σου. Προσωπικά πάντως μπαίνω στον κόπο (δε θεωρώ πως είναι κόπος, σχήμα λόγου φαντάζομαι) να έχω άλλο format όπου μπορώ, εξάλλου δεν είναι και πάντα στο χέρι σου -- αν π.χ. έχεις δύο διαφορετικά code bases στη δουλειά με διαφορετικά style τότε μπαίνεις στον κόπο θες δε θες. Κι αν δουλεύεις open source ακόμα πιθανότερο. Έτσι κι αλλιώς όλα τα σοβαρά IDE υποστηρίζουν per-project code style οπότε δεν υπάρχει πρακτικό εμπόδιο.

 

Σχετικά με το lambda, και με την επιφύλαξη ότι σε μια τέτοια συζήτηση σίγουρα περνάμε στον άλλο μόνο ένα ελάχιστο ποσοστό απ' αυτά που έχουμε στο μυαλό μας: νομίζω πως στη γενική περίπτωση αν χρειάζεται να δεις το definition για να καταλάβεις τι γίνεται στο call site, you are doing it wrong. Επίσης, βάζοντάς τον κώδικα για μια method μέσα σε μια άλλη (αυτό κάνεις στην ουσία) καταφανώς παραβιάζεται το single responsibility principle και πρακτικά αν το αφήσεις unchecked καταλήγεις να έχεις monster methods με όλα τα προβλήματα που αυτό συνεπάγεται.

 

Σχετικό: http://programmers.stackexchange.com/questions/184037/descriptive-naming-vs-80-character-lines

Μπορείς αν ορίζεις εσύ το format που πρέπει να ακολουθεί η ομάδα

 

Μιλάμε για ένα case όπου απλά το expression είναι μεγάλο έτσι; Με την περιγραφή σου στην ουσία καταργείς τα lambdas τα οποία εξ' ορισμού είναι functions μέσα σε functions επίσης ούτε θέμα με το test coverage δημιουργείτε, αν υπονοείς αυτό. Είναι σαν να μου λες να μην γράφω linq με lamdas γιατί είναι μέσα σε άλλο function και "παραβιάζεται το single responsibility principle".