Na przykład wyrównanie w pionie:
Name: Hamt
Version: 0.1.0
Cabal-Version: >= 1.2
License: BSD3
Author: Jason Baker
Lub wyrównany w pionie:
Name: Hamt
Version: 0.1.0
Cabal-Version: >= 1.2
License: BSD3
Author: Jason Baker
Który wolisz i dlaczego?
code-layout
whitespace
coding-standards
Jason Baker
źródło
źródło
:%s/\([^ ]\) \+/\1 /gWolę hybrydę:
Który jest zasadniczo numerem 2 z wyjątkiem wyjątkowych linii, które są dłuższe niż linie otaczające - aby zapobiec znacznej odległości większości linii.
źródło
Oto kolejna odmiana układów list na podstawie zarówno doświadczenia, jak i wykształcenia z kursu uniwersyteckiego, w którym brałam udział w interakcji człowiek-komputer oraz kilku książek, które przeczytałem na temat projektowania (G) interfejsu użytkownika i projektowania graficznego. Używam go do dialogów, a kiedy mam energię / czas, do CSS (zwykle nie do kodu).
Jak wszystkie inne, ma swoje zalety i wady.
Plusy:
Cons:
HTH
źródło
Wolę pierwszy, ale bez zakładek (które, jak sądzę, są puste); zamiast tego tylko jedno puste miejsce. Dla mnie jest to łatwiejsze do odczytania, gdy dane nie są „podobne”, jak w danym przypadku. Utrudnia także (podczas edycji takich danych) „błędne odczytanie wiersza”, tzn. Gdy masz trzy wiersze z, powiedzmy, numerami wersji. A następnie podczas edycji jednego, przypadkowo edytujesz inny na swoim miejscu.
Gdy dane są podobne, warto je umieścić w kolumnach, jak w drugim przykładzie (tylko, że nie jest podobny, ale rozumiesz).
źródło
Niestety jest to pytanie o styl, jest to bardzo subiektywne i prawdopodobnie będziesz mieć wiele sprzecznych wyników. Ponadto styl użytkowania zależy w dużym stopniu od użycia tabulatorów lub spacji.
Jeśli chodzi o moje dwa centy, wolę wariant drugiej wersji. Najbardziej to lubię:
Jest to najbardziej czytelna i łatwa w użyciu wersja, którą wypróbowałem. Jedynym prawdziwym minusem jest to, że muszę dowiedzieć się, jakie jest najszersze pole, a czasami muszę rozwinąć je wszystkie, gdy jedno jest zbyt szerokie (zwykle dzieje się tak tylko w CSS). Należy jednak wziąć pod uwagę kilka punktów.
Po pierwsze, zwykle wolę tabele zamiast spacji, jednak rzeczywiste ustawienie tabulacji jest różne; na przykład jestem przyzwyczajony do 4-spacji TAB dla kodu C (++) lub HTML i 2-spacji TAB dla kodu Pascal lub Asemblera, podczas gdy w niektórych rzeczach, takich jak CSS, nie mam preferencji co do szerokości TAB. Ta odmiana dość komplikuje rzeczy, ale potem edytor, którego używam, rzuca swoje własne komplikacje. Niektóre edytory pozwalają ustawić ustawienia TAB dla poszczególnych języków, ale niektóre nie (nawet te, które mają inne profile).
Możesz uniknąć tej komplikacji, rezygnując z TAB na rzecz spacji. Ponieważ kod jest zwykle czcionką o stałej szerokości, używanie spacji działa dobrze, natomiast jeśli formatujesz pola w formularzu, wznawiasz lub inny tekst inny niż kod i używasz czcionki proporcjonalnej, będziesz potrzebować tabulatorów, aby zachować wyrównanie .
Ogólnie wolę tabulatory, ponieważ nawet przy kodzie o stałej szerokości frustrujące jest przechodzenie między kilkoma spacjami dla każdej tabulacji. Pamiętam, że stare IDE Borlanda miały opcję przewijania TAB (konkretnie całe długości białych znaków) jako pojedynczego elementu zamiast dwóch, czterech itd. Spacji. Dzięki temu wstawianie tabulatorów jako spacji jest praktyczne, a nawigacja kursorem jest łatwa i szybka. Niestety nie widziałem żadnych nowoczesnych edytorów Windows, które mogłyby to zrobić.
Wreszcie, to, czy inni będą używać Twojego kodu, odgrywa dużą rolę w wyborze stylu. Zwykle jestem jedynym, który używa mojego kodu, więc mogę sformatować wszystko zgodnie z moim gustem, bez względu na edytory lub ustawienia innych. Jeśli pracujesz z innymi, musisz wziąć je pod uwagę, ponieważ będą musieli wziąć pod uwagę ciebie.
Podsumowując, czytelność jest dobra i bardzo pożądana, jednak ustawienia i edytory, które Ty i inni, którzy muszą używać kodu, będą ważne przy podejmowaniu decyzji. Jeśli jesteś sam, równie dobrze możesz użyć formatu, który jest najbardziej czytelny. Być może będziesz musiał się przyzwyczaić do korzystania z niego, ale na dłuższą metę prawdopodobnie się to opłaci, zwłaszcza gdy będziesz musiał wrócić do kodu napisanego jakiś czas temu: czytelność jest tak samo ważna jak komentarze w zrozumieniu tego, co robi kod. Jeśli pracujesz z innymi, będziesz chciał współpracować, aby opracować jakiś przewodnik projektowy do użytku przez zespół.
źródło