Wyrównanie w pionie: tak czy nie? [Zamknięte]

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?

Osobiście uważam, że druga wersja kodu jest nieznacznie bardziej czytelna, ale nie sądzę, że utrzymanie go nadrabia tę czytelność. Dlatego użyłbym drugiej wersji tego przykładu tylko wtedy, gdy byłem dość pewien, że kod się nie zmieni.

Oszczędza czas, gdy robisz to w ten sposób:

Name: Hamt
Version: 0.1.0
Cabal-Version: >= 1.2
License: BSD3
Author: Jason Baker

Nie jest też zbyt trudne do odczytania.

Wolę hybrydę:

Name    : Hamt
Version : 0.1.0
Cabal-Version :  >= 1.2
License : BSD3
Author  : Jason Baker

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.

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).

          Name : Hamt
       Version : 0.1.0
 Cabal-Version : >= 1.2
       License : BSD3
        Author : Jason Baker

Jak wszystkie inne, ma swoje zalety i wady.

Plusy:

• Silna wizualna przerwa oddziela dane od etykiet
• Estetyczny, profesjonalny wygląd graficzny (szczególnie w przypadku sfinalizowanych, opublikowanych plików)
• Dane są bliżej etykiety, co ułatwia kojarzenie (zmniejsza szanse na odczyt z niewłaściwych danych wzdłuż linii)
• Idealny do układów okien dialogowych

Cons:

• Wymaga więcej czasu na prawidłowe sformatowanie
• Wymaga zmiany ustawienia po dodaniu nowego najdłuższego przedmiotu
• Nie tak przydatne dla kodu

HTH

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).

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ę:

Name            : Hamt
Version         : 0.1.0
Cabal-Version   : >= 1.2
License         : BSD3
Author          : Jason Baker

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ół.