Dlaczego gadatliwość jest zła dla języka programowania? [Zamknięte]


98

Widziałem wielu ludzi narzekających na gadatliwość języków programowania. Uważam, że w pewnych granicach, im bardziej szczegółowy jest język programowania, tym lepiej jest go rozumieć. Myślę, że gadatliwość wzmacnia także pisanie APIdla tego konkretnego języka.

Jedyną wadą, o której mogę pomyśleć, jest to, że sprawia, że ​​piszesz więcej, ale to znaczy, większość ludzi używa IDE, które wykonują całą pracę za Ciebie.

Więc jakie są możliwe wady pełnego języka programowania?


20
Czy ostatnio kodowałeś w APL?
SK-logic

5
Sprawdź języki, gadatliwość i Java autorstwa Dhanji R. Prasanny
Jeremy Heiler

66
„Deweloper ma tylko pewną liczbę naciśnięć klawiszy, zanim umrze”
CamelBlues

10
Być może powinieneś zapytać „wiele osób narzekających”, jakie są ich powody.
Eric Lippert

29
@EricLippert, uważam, że P.SE jest idealnym miejscem do zapytania dużej liczby „narzekających” programistów.
Kevin McCormick

Odpowiedzi:


168

Celem jest szybkie zrozumienie

„Pełne” oznacza „używa zbyt wielu słów”. Pytanie brzmi, czym jest „zbyt wielu”.

Dobry kod powinien być łatwy do zrozumienia na pierwszy rzut oka. Jest to łatwiejsze, jeśli większość znaków służy bezpośrednio kodowi .

Sygnał a hałas

Jeśli język jest pełny, więcej kodu to szum. Porównaj „Hello World” Javy :

class HelloWorldApp {
    public static void main(String[] args) {
        System.out.println("Hello World!");
    }
}

... z Ruby's:

print "Hello World!"

Hałas marnuje energię psychiczną.

Cryptic vs. Clear

Z drugiej strony nadmierna zwięzłość języka również kosztuje energię psychiczną. Porównaj te dwa przykłady z Common Lisp :

(car '(1 2 3))   # 3 characters whose meaning must be memorized
# vs
(first '(1 2 3)) # 5 characters whose meaning is obvious

19
Powiedziałbym, że to drugie dotyczy czytelności na poziomie mikro (gdzie zwykle wolimy bardziej szczegółowe notacje), gdzie tak jak pierwsze dotyczy czytelności na poziomie makro (gdzie zwykle wolimy więcej zwięzłości)
jk.

67
Dla każdego programu, który faktycznie coś robi, Java często staje się znacznie bardziej czytelna, szczególnie przy dobrym wykorzystaniu biblioteki.

9
w rzeczywistości lepszym przykładem gadatliwości w skali makro mogą być wzorce, które działają wokół brakującej funkcji językowej
jk.

21
Powiedziałbym, że ten przykład z Javą też nie jest najlepszy. Takie rzeczy jak potrzeba zdefiniowania klasy i metody mają znaczenie w golfie kodu, ale prawie nie w rzeczywistych zastosowaniach. To nie tak, że Java wymaga dużo kodu do wypisania kilku słów, te kilka wierszy jest wymaganych do stworzenia programu, i to jest inne.
Malcolm

27
+1 dla rozróżnienia pomiędzy Signal vs. Hałas i Cryptic vs. Wyczyść
Spoike

118

Wpływa na to, ile kodu można zobaczyć i parsować jednym spojrzeniem

x++ zamiast set(x,Integeradd(get(x),1))

ps. Nie chodzi tylko o czytanie kodu. W czasach ekranów 40 x 25 języki APL lub Perl były przydatne w Cobol lub Fortran pod względem ilości kodu, który można odczytać / stronę. Ale teraz chodzi bardziej o twoją wewnętrzną pamięć podręczną - jeśli instrukcja ma jednego operatora, mój starzejący się mózg łatwiej analizuje niż jeden z 3 symbolami i 4 wywołaniami funkcji.


19
Wierzę, że to jest ostateczny powód. Czytelność na ograniczonej przestrzeni, takiej jak kartka papieru lub monitor.

1
+1 i całkowicie się zgadzam, a ja
koduję na 13

1
@ZJR - patrz edycja.
Martin Beckett

3
Więc co robi settutaj metoda? Czy faktycznie coś ustawia (tj. Pierwszy xparametr), czy też zwraca coś (tj. Przypisanie do xpo wywołaniu)? Powiedziałbym, że w pełnym opisie dzieje się coś dziwnego.
Jesse C. Slicer

8
Brakuje tutaj tylko użyteczności ideografów - że symbole mogą mieć większe znaczenie niż słowa. Np. Ma +większe znaczenie niż plus. =jest lepszy niż equals. To oczywiście można posunąć za daleko (i było to w kilku językach), ale gdy jest używane z umiarem, jest bardzo potężne.
mcmcc

29

Jeśli gadatliwość języka szkodzi czytelności kodu, jest zła.

Niektóre języki mają taką pełną składnię, że zrozumienie znaczenia kodu trwa dłużej (myślę o VB.NET w porównaniu do C #):

If something Then
End If

if(something)
{}

To naprawdę sprowadza się do tego, co programista zna i czuje się komfortowo.


6
Pracuję głównie w C #, ale kiedy czytam VB, stwierdzam, że czytam to tak, jakby to był C #. Ignoruję wszystkie If .. Then .. End Ifi czytam tylko to, co ważne.
Andy Hunt

7
tak samo jak Andy. Uważam oba za równie czytelne. Powiedziałbym nawet, że wolę trochę wariant VB (mimo że jestem bardziej przyzwyczajony do c #).
Dagnelies

9
VB.NET nie jest gadatliwy w porównaniu do innych gorszych przestępców!

3
@AndyBursh - Dokładnie mój punkt. Czytając VB.NET, wykonujesz tłumaczenia mentalne ponad rozumieniem kodu.
Oded

6
Oded, End-If jest znacznie łatwiejszym do zrozumienia konstruktem na końcu instrukcji if niż nawiasów, gdy nawiasy są zagnieżdżone wewnątrz innej instrukcji if, wewnątrz pętli, wewnątrz innej pętli, wewnątrz funkcji, która jest wewnątrz Klasa. Wszystkie wyżej wymienione bloki używają tych samych nawiasów, co oznacza, że ​​próba ustalenia, który z nich jest nawiasami końcowymi, jest mniej intuicyjna.
Andrew Neely,

27

Spójrz na AppleScript , jeden z najbardziej gadatliwych języków, które mogę wymyślić, które można uznać za aktualny , spróbuj napisać w nim coś trywialnego i wróć i spróbuj argumentować, że gadatliwość jest dobrą cechą w języku.

Próba zapamiętania całej semantyki tego, gdzie idą słowa kluczowe i co to są, nie jest trywialna, jeśli nie robisz tego codziennie.

Wystarczy spojrzeć na wszystkie słowa kluczowe hałas w tym trywialnym przykładzie:

tell application "Finder"
    if folder "Applications" of startup disk exists then
        return count files in folder "Applications" of startup disk
    else
        return 0
    end if
end tell

przyznanie tego samego w bashprzypadku tradycyjnych narzędzi uniksowych byłoby zwięzłe, ale tajemnicze dla większości użytkowników OSX, więc należy zachować równowagę.


15
Nie chciałeś tego return the 0podczas pisania? AppleScript to jedyny język, który znam, który pozwala lamentować słowa kluczowe przeciwnikom ... Mam na myśli współpracowników.
ccoakley

Applescript IDE, edytor skryptów z lat 90., pomagał w szczegółowym radzeniu sobie z nagrywaniem akcji za pomocą AppleScript , nie był strasznie sprytny, ale przydał się podczas skryptowania Findera ... około 1998 r. nagranie się rozpadło i nigdy nie zostało naprawione . (nie wiem, czy przejście OSX to naprawiło, IIRC, nie)
ZJR

3
Odpowiedź OSX na kłopotliwość AppleScript to Automator. Zamieńmy łatwy do pisania tekst na gigantyczną bibliotekę przeciągalnych, opisywanych i słabo wyjaśnionych bloków funkcyjnych!
puszysty

Najgorsze w AppleScript jest to, że każda aplikacja, którą chcesz nim obsługiwać, może mieć inną terminologię. Apple definiuje pewne zestawy poleceń, które powinny obsługiwać wszystkie programy, ale ogólnie rzecz biorąc, wiedza na temat pisania skryptów w jednej aplikacji ma jedynie ograniczoną pomoc w pisaniu skryptów w innej.
kindall

1
Applescript jest nieporęczny do pisania, ale łatwy do zrozumienia dla człowieka ... w granicach programistów umieszczających applecript z zrozumiałą składnią w sterowanej aplikacji.
aramis

23

Myślę, że musisz postawić pytanie na głowie i zapytać: Dlaczego niektórzy ludzie uważają, że zwięzły kod jest dobry?

Moja odpowiedź byłaby taka, że ​​istnieją dwa podstawowe powody:

Powody, dla których Terse może być lepszy

Obejmują one większą czytelność, podobnie jak krótkie zdanie może być bardziej zrozumiałe niż kwieciste zdanie pełne. Często języki programowania, które próbują naśladować gramatykę języka angielskiego, są okropnie długie, co wymaga ogromnej ilości kodu do wykonania najprostszych czynności. Często okazuje się, że im bardziej język emuluje język pisany, tym trudniej jest go przekonać do wykonywania logicznie skomplikowanych operacji.

Powody, dla których Terse może być gorzej

Niektóre języki (a myślę o Perlu) używają szeregu dziwnych symboli, które wydają się być prawie arbitralnie wybrane, jako część ich składni. Dla każdego, kto nie zna tych hieroglifów, język staje się nieprzenikniony. Łatwo jest również popełniać błędy literowe, które nie są łatwo widoczne. Wyrażenia regularne mogą być uosobieniem tego rodzaju zwięzłości.

Ponadto niektórzy ludzie lubią się popisywać pisząc zwięzły kod, ponieważ, szczerze mówiąc, myślą, że dzięki temu wyglądają sprytniej. Czasami można to zobaczyć na StackOverflow, gdzie ludzie często przesyłają odpowiedzi, które są niezwykle zwarte kosztem czytelności. Jest to rodzaj „imponowania rówieśnikom” tym, jak dobrze znasz filozofię, ale dobrzy programiści zdają sobie sprawę, że „ golf golfowy ” nie jest sposobem na tworzenie oprogramowania, które można utrzymać.


Nie uważałbym, że zwięzłe przeciwieństwo gadatliwości. Verbose niesie negatywne skojarzenia, więc prawdopodobnie lepiej nadawałby się do antonimów o pozytywnych konotacjach.
Joshua Drake

6
tersejest antonimem verbose, tersemoże mieć taką samą negatywną konotację (patrz Perl)

1
@JarrodRoberson: Nienawidzę być pedantyczny w piątkową noc wszystkich rzeczy, ale przyjrzałem się kilku tezaurusom online i żadna z nich nie tersema antonimu verbose(lub odwrotnie). / kaczki
Scott Mitchell


15

@frowing, sugerowałbym, że jednym ze sposobów spojrzenia na kwestię gadatliwości jest uświadomienie sobie, że programowanie to zawsze połączenie dwóch raczej różnych stylów znalezienia i wyrażenia rozwiązania.

Pierwszym i bardziej pełnym stylem jest programowanie zorientowane na język (językoznawczy). Ten styl łączy słowa podobne do rzeczowników i słowa podobne do czasowników w strukturach podobnych do zdań i jest przeznaczony do czytania i rozumienia w taki sam sposób, jak dobrze napisany akapit. Programowanie językowe jest najbardziej uniwersalnym stylem programowania, ponieważ sam język jest uniwersalny. Z tego samego powodu długoterminowe wsparcie programu zawsze wymaga potężnego komponentu językowego, ponieważ pierwszą rzeczą, której szuka nowy programista, jest koncepcyjne zrozumienie tego, co się dzieje. Zasadniczo im dalej od kontekstu, w którym utworzyłeś program, tym ważniejszy będzie język programowania, aby upewnić się, że twoje założenia i koncepcje nie zostaną źle zrozumiane przez następną osobę próbującą zrozumieć Twój kod .

Drugi i bardziej zwięzły styl to programowanie matematyczne (matematyczne). Ten styl rozumowania zależy również od języka, ponieważ na przykład zmienne są analogiczne do rzeczowników, a operatory do czasowników. Jednak rozumowanie matematyczne wykorzystuje niesamowitą i wysoce równoległą zdolność naszych mózgów do wykonywania złożonych transformacji przestrzennych na obiektach znajdujących się w naszej linii widzenia. Reprezentując rzeczowniki i czasowniki jako zwarte, charakterystyczne symbole, które można ułożyć w dobrze ustrukturyzowane wyimaginowane obiekty - równania - możemy następnie wykorzystać nasze wysoce równoległe możliwości wizualne do wykonywania obrotów, zamian, ruchów, inwersji i innych przekształceń na tych wyobrażonych przedmioty Rezultatem jest ogromne zwiększenie liczby przypadków, które możemy obsłużyć jednocześnie, ponieważ każdy symbol może reprezentować całe klasy blisko spokrewnionych obiektów.

Zauważ, że aby efektywnie zastosować przetwarzanie wizualne, musisz utrzymywać swój wymyślony obiekt tak podobny, jak to możliwe, pod względem wielkości i cech do rzeczywistego obiektu. Jeśli potrzebne pole widzenia staje się zbyt szerokie lub symboli nie można używać jak ruchomych znaków na obiekcie, lub jeśli trzeba „czytać litery” i konwertować je na słowa, zdolność niezawodnego wykonywania złożonych przekształceń spadnie szybko nawet dla bardzo dobrego matematyka.

Dlatego ludzie głęboko zanurzeni w matematycznym stylu programowania mogą stać się poważnie niezadowoleni, jeśli równanie zostanie rozłożone i wyrażone w tak zwanym „pełnym” stylu językowym. Nie dlatego, że równanie zostało znacząco zmienione, ale dlatego, że takie jego rozłożenie może prawie uniemożliwić zastosowanie wizualnego stylu zrozumienia. Jednocześnie jednak nowy programista, który wcale nie jest zaznajomiony z krótkimi symbolami, prawdopodobnie preferuje bardziej szczegółową wersję, która zapewnia więcej informacji językowych do początkowego zrozumienia działania kodu.

Co więc poleciłbym?

Użyj obu stylów, ale zwróć szczególną uwagę na to, dlaczego używasz każdego z nich.

Na przykład wszystko, co ma szansę na kontakt ze światem zewnętrznym, powinno być na pewnym poziomie intensywnie gadatliwe, nawet jeśli tylko w formie komentarzy wewnętrznych połączonych z kodem, i powinno również obejmować automatyczne sprawdzanie poprawności użycia. Zaszyfrowane, a zwłaszcza niekompletnie zdefiniowane notacje nie mają nic wspólnego z takimi interfejsami, ponieważ prawie na pewno w pewnym momencie zostaną źle zrozumiane. Utrata Mars Climate Obiter w 1999 r. Z powodu nierozpoznania, czy jednostki interfejsu oprogramowania zostały wyrażone w funtach czy Newtonach, jest szczególnie wyraźnym przykładem niebezpieczeństwa polegającego na zbyt swobodnym poleganiu na surowych liczbach w interfejsach programowych lub sprzętowych.

I odwrotnie, każda forma programowania, która jest z natury głęboko algorytmiczna i matematyczna, jest dobrym kandydatem na zwięzłe programowanie, które obsługuje matematyczny styl rozumowania. Jeśli ktoś nowy musi zachować taki kod, zwykle lepiej jest nauczyć się notacji matematycznych niż próbować przekształcić kod w bardziej pełne formy. Oczywiście zawsze powinna być łatwo dostępna dokumentacja wyjaśniająca matematyczne części kodu dostępnego dla takich programistów, ale jest to osobna kwestia.

Pomiędzy tymi ekstremami jest wiele przypadków, w których programista ma znaczną dyskrecję. Proponuję przyjrzeć się, w jaki sposób kod będzie utrzymywany w perspektywie długoterminowej, i starać się zaspokoić potrzeby osób, które prawdopodobnie utrzymają kod w perspektywie długoterminowej.


8

Wiele osób wskazało na coś, co moim zdaniem powinno być wyraźnie określone.

Gadatliwość sprzyja zrozumieniu na poziomie mikroskopowym - generalnie prowadzi do tego, że indywidualne stwierdzenie jest łatwe do odczytania i zrozumienia. Gadatliwość ma również tendencję do zmniejszania stopnia znajomości języka niezbędnego do jego zrozumienia (przynajmniej do pewnego stopnia). Najbardziej szczegółowe języki (np. COBOL) mogą być przynajmniej w pewnym stopniu czytelne nawet dla kompletnych nieprogramistów.

Konkluzja zmierza w przeciwnym kierunku: pomaga zrozumieć na poziomie makroskopowym, szczególnie przez programistów, którzy mają najgłębszą znajomość tego konkretnego języka. Jednocześnie brak znajomości tego konkretnego języka może uniemożliwić nawet podstawowe zrozumienie, nawet ze strony programistów, którzy w innym przypadku byliby dość doświadczeni.

W związku z tym czytelność różni się znacznie w zależności od grupy docelowej. Z jednej strony rozważmy, że duży, złożony projekt jest napisany i prowadzony przez osoby, które pracują prawie wyłącznie nad tym projektem, z których większość ma znaczne wykształcenie programistyczne i wykształcenie (np. Wiele doktoratów). Sprzyja to bardziej zwięzłemu językowi.

Mniej więcej przeciwnie, rozważ projekt, który jest znacznie prostszy (choć być może wciąż dość duży), który jest prowadzony przede wszystkim przez ludzi, którzy naprawdę specjalizują się w działalności związanej z oprogramowaniem, a nie z samym oprogramowaniem. To prawie na pewno faworyzuje bardziej szczegółowy język.


6

Zamiast iść do książki technicznej, wracam do Elements of Style * autorstwa Strunk and White. Podstawową koncepcją jest „Bądź precyzyjny” i „Nie mów więcej niż to konieczne”. Cała reszta to komentarz.

W programowaniu chodzi o to, by być bardzo precyzyjnym, ale nie mieć zbędnego puchu. Dodatkowy puch może być składniowy, ale może także zawierać więcej słów niż jest to wymagane do przekazania znaczenia. (Oczywiście nie jest też za mało, aby umożliwić dwuznaczność)

  • Cytuję oryginalną wersję, ponieważ jest ona najbardziej zwięzła. :-)

5

Pod koniec dnia wszystko, co „inne” spowoduje, że ludzie wyją. Czuję się swobodnie ze składnią w stylu C, a zatem dobrze z innymi językami o podobnej składni (C ++, Java, C #). Więc mam tendencję do faworyzowania tego konkretnego stylu.

Języki mają tendencję do znajdowania równowagi między wystarczająco opisowym, a nie pełnym.

Perl jest przykładem, gdzie możesz napisać bardzo zwięzły kod. Dla niewtajemniczonych kod napisany przez ninja Perla to magia.

COBOL jest przykładem zbyt gadatliwym.


5
Jak to odpowiada na pytanie?
ChrisF

gadatliwość jest inna dla każdego. Taki był cel mojego komentarza. Jeśli jesteś w obozie C / C ++, zaakceptowana gadatliwość jest inna niż w obozie perl.
Nasir

kod napisany przez perla ninja jest niczym magicznym? Poważnie, myślę, że to koszmar.
Kevin

omijam perla :)
Nasir

Dla programistów język COBOL może być zbyt szczegółowy w porównaniu do innych języków. Jednak dobrze napisany język COBOL może być łatwy do odczytania dla klientów biznesowych. To pozwala im sprawdzić, czy kod robi to, czego potrzebują, czytając go.
BillThor,

4

Czytałem kiedyś gdzieś, że duża część szczegółowej debaty pochodzi od nowych programistów kontra stare ręce. Zastosowana analogia była taka, że ​​kiedy uczymy się czegoś nowego, opowiadamy sobie „historię”, aby się przez to przejść (pomyśl o tym, kiedy nauczyłeś się algebry w HS). W miarę zdobywania doświadczenia wychodzimy poza potrzebę opowiadania wyjaśniającego poszczególne elementy i rozumiemy większą ich liczbę. Nasz kod staje się gęstszy i bardziej zwięzły, a komentarze wyjaśniają tylko niezbędne elementy, zamiast powtarzać to, co mówi kod.

Odkryłem, że to prawda między mną a współpracownikiem. Pisze kod z mnóstwem komentarzy wyjaśniających, jakie są wiersze kodu i dużą ilością białych znaków. Jeśli to czytam, stwierdzam, że z tego powodu mogę zmieścić tylko kilka wierszy kodu na jednym ekranie. To sprawia, że ​​zrozumienie każdej linii jest znacznie łatwiejsze, ale omawianie całej funkcji staje się znacznie trudniejsze.

Zwykle piszę kod bez dodatkowych białych znaków i komentarzy. To sprawia, że ​​oglądanie całości jest znacznie łatwiejsze, ale musisz być w stanie po prostu „zdobyć” poszczególne słowa „kodu”. Jeśli spróbujesz przeczytać tę odpowiedź, gdy każde słowo znajduje się w osobnym wierszu, z dużą ilością białych znaków / komentarzy / dodatkowego słownictwa, znacznie łatwiej będzie zrozumieć każde słowo, ale o wiele trudniej zrozumieć całość.


Nikt nie jest przeciwny komentarzom. Problemem są języki takie jak Java, AppleScript lub Visual Basic, które zawierają wiele zbędnych, ale obowiązkowych elementów.
Marcin

2
@Marcin Nie jestem też przeciwny komentarzom, ale kiedy są takie: i++; //this is adding one to var ijest zbędne.
Spencer Rathbun

Pytanie dotyczy jednak języków programowania.
Brendan Long

2
@BrendanLong Hmm, może nie byłem jasny. Niepotrzebne komentarze utożsamiałem z pełnymi językami programowania. Wiele słów, aby powiedzieć to samo, tylko pełny język programowania wymaga ich przez cały czas.
Spencer Rathbun

Można argumentować, że i tak funkcja nie powinna składać się z więcej niż kilku linii. Jeśli trudno jest zrozumieć, jak działa ta funkcja, prawdopodobnie nie jest to spowodowane zbyt dużą liczbą komentarzy. Zgadzam się jednak, że lepiej unikać komentarzy, które mówią tylko to, co natychmiast jest jasne.
lewo około

4

Einstein miał rację: „Spraw, aby wszystko było tak proste, jak to możliwe, ale nie prostsze”.

Dotyczy to również kodu. Jeśli możesz uprościć kod poprzez usunięcie powtarzających się i niepotrzebnie pełnych elementów, to dobrze.

Ponadto niektóre studia przypadków sugerują, że produktywność programisty mierzona w liniach kodu jest mniej więcej stała. Tak samo jak liczba błędów na LOC. Dlatego przejście na język, który pozwala robić więcej na wiersz kodu, można uznać za poprawę wydajności, jeśli wszystkie inne rzeczy pozostaną takie same.

Biorąc to pod uwagę, w tej branży występuje tendencja do nadmiernej inżynierii i komplikowania prostych rzeczy. Proste rzeczy, takie jak umieszczanie danych kontaktowych w relacyjnej bazie danych. Widziałem kilka absurdalnie skomplikowanych i błędnych rozwiązań ( kaszel MDA) dla tego konkretnego problemu. Języki takie jak Scala i Ruby są dobrymi przykładami potężnych narzędzi, które w rękach niektórych osób powodują niezrozumiały, zbyt skomplikowany i trudny w utrzymaniu kod. To, że możesz użyć wielu poziomów pośrednich za pomocą kilku klawiszy, nie oznacza, że ​​musisz wyrywać każdy gwóźdź w zasięgu wzroku za pomocą tego konkretnego młotka.

Przy właściwym użyciu otrzymujesz ładny, czysty kod, który jest zarówno krótki, jak i łatwy do zrozumienia. W przypadku złego użycia lepiej jest ograniczyć daną osobę do używania języka Visual Basic lub podobnie ograniczonego języka, aby zapobiec dalszym szkodom.

Prawdziwa umiejętność polega na robieniu skomplikowanych rzeczy w prosty sposób, a nie na robieniu prostych rzeczy w skomplikowany sposób.


3

Coś, czego nikt inny nie trafił, to ilość kodu, którą można zmieścić na jednym ekranie. Pomaga z kilku powodów:

  • Mniej przewijania w przód iw tył, gdy pracujesz (lub czytasz) wiele funkcji w jednym pliku.
  • Mniej przewijania w poziomie (zatrzymaj czytanie, kliknij i przeciągnij pasek przewijania, zatrzymaj czytanie, kliknij i przeciągnij pasek przewijania ...).
  • Szybsze skanowanie, ponieważ mniej niepotrzebna składnia przeszkadza w znalezieniu tego, czego chcesz.

naprawdę, ile przewijania wykonuje się na ekranie 1920 X 1080 przy rozsądnie czytelnym rozmiarze czcionki? Istnieją również te rzeczy, zwane skrótami klawiaturowymi do nawigacji w obu kierunkach.

@JarrodRoberson - Mój ekran pokazuje około 30 linii. Jeśli sprawię, że okno kodu będzie pełnoekranowe i zmniejszy rozmiar czcionki, aby był ledwo czytelny, otrzymam 60 linii. Musiałem pracować na kilku tysiącach plików liniowych (zapewniam, że nie z wyboru). Używam „nawigatora” w moim IDE, ale wciąż nie jest to tak wygodne, jak przeglądanie dwóch sekcji kodu, które są na ekranie.
Brendan Long

Czy twoje IDE nie obsługuje podzielonych widoków?
lewo około

2
Oboje nie rozumiecie sedna - niezależnie od tego, czy moje IDE może sprawić, że przewijanie będzie mniej złe , nigdy nie będzie tak dobre, jak wcale nie przewijanie (lub używanie skrótów klawiszowych lub podziału ekranu) . To tak, jakby powiedzieć: „Klawiatury ekranowe są w porządku, czy nie słyszałeś nigdy o klikaniu?”; Oczywiście, że tak, ale nie jest tak, że mam prawdziwą klawiaturę.
Brendan Long

Niejasno pamiętam, że tak naprawdę istnieją badania, które to potwierdzają (szczególnie część przewijana). Konieczność przewijania, aby zobaczyć całą jednostkę logiczną, utrudnia zrozumienie. Przynajmniej brzmi wiarygodnie.
Konrad Rudolph

1

Ponieważ więcej kodu oznacza dłuższy czas programowania i więcej błędów.

Jeśli napiszesz 100 wierszy kodów zamiast 300 wierszy kodów. Oznacza to prawie 1/3 potrzebnego czasu rozwoju i 1/3 potencjalnych błędów, które możesz napotkać.

W większości przypadków trzeba zrównoważyć wydajność i zwięzłość, ponieważ pisanie mniejszej liczby kodów oznacza, że ​​maszyna musi robić więcej rzeczy, co obniża wydajność.


2
Spodziewałbym się o wiele więcej ukrytych błędów w 100 typowych liniach Perla niż w 300 liniach Ady. - Jeśli chodzi o „ponieważ pisanie mniej kodów oznacza, że ​​maszyna musi robić więcej rzeczy, co obniży wydajność”, może istnieć taka korelacja, ale to nie jest przyczynowość. Tyle, że zwięzłe dynamiczne i / lub interpretowane języki, takie jak Ruby, Perl i Python, wydają się być wolniejsze niż bardziej szczegółowe języki kompilowane statycznie, takie jak C lub Fortran. Ale zwięzłe kompilowane programy Haskell, Python w / PyPy lub C ++ mogą być znacznie szybsze niż szczegółowe, np. Interpretowany kod Basic, Groovy, Smalltalk, a nawet C #.
lewo około

1

Zwykle ludzie wolą języki czytelne / pełne niż kryptyczne / zwięzłe. Myślę jednak, że większość ludzi przyswoiła sobie „gadatliwość” z „bałaganem”, które nie są tym samym.

Na przykład: while(<>){print if($.==2 || $& && !$x++); $.=0 if (/^--+$/)}

jest bardzo zwięzłym stwierdzeniem. Zawiera wszystko, co chcesz wiedzieć. Jednak ze względu na zwięzłość trudno ją zrozumieć. Z drugiej strony nieco bardziej szczegółowa wersja tego samego programu byłaby dość łatwa do zrozumienia, ponieważ jest bardziej czytelna. Oczywiście nie jest to właściwość języka jako takiego, ale niektóre języki mają tendencję do większej gadatliwości, podczas gdy inne mają tendencję do bardziej zwięzłego sposobu programowania.

Do drugiej skrajności gadatliwości należy http://en.wikipedia.org/wiki/Literate_programming , co uważam za dość interesującą koncepcję.

Innym aspektem jest „niechciana gadatliwość”, zwana także „bałaganem”. Rzeczy, które musisz dodać z przyczyn technicznych, brak cukru syntaktycznego, rozdęte API i tak dalej.

Myślę, że jasna i intuicyjna składnia jest bardzo ważna. Musi być również wystarczająco szczegółowe, aby ułatwić czytanie. Zbyt krótkie wypowiedzi wypełnione zbyt dużą logiką mogą często prowadzić do rozszyfrowania więcej niż ich nieco dłuższe odpowiedniki. Z drugiej strony, bezużyteczny, rozdęty kod pełen linii kotłów do zrobienia czegoś całkowicie prostego jest równie uciążliwy.


4
Możesz dokładnie sprawdzić [znaczenie zwięzłego] ( en.wiktionary.org/wiki/concise ), ponieważ jest to prawie antonim tajemniczy. Czy może kodujesz w Javie?
Joshua Drake

2
Wolę pełny kod napisany w zwięzłych językach.
Brendan Long

@Joshua: tak, zauważyłem, że można to interpretować na bardzo różne sposoby, więc zredagowałem swoją odpowiedź. ... i co ma z tym wspólnego Java?
Dagnelies 23.03.12

1
Komentarz do stwierdzenia, dlaczego został odrzucony, może być bardziej interesujący niż sama opinia.
Dagnelies 23.03.12

@arnaud my bad za korzystanie z wikisłownika. Wyszukiwarka google definiuje: zwięzłe rozpoczyna się: „Wyraźnie podaje dużo informacji”, co wyraźnie narusza twój przykładowy kod. Chociaż muszę uznać pierwotną implikację zwięzłości, jasne i zwięzłe teraz podróżują razem.
Joshua Drake

1

Gadatliwość to tendencja do używania dużej ilości tekstu, a zwięzłość użycie bardzo małej ilości tekstu ...

Gadatliwość jest zła, ponieważ:

  1. wprowadza więcej okazji do błędów typograficznych
  2. utrudnia to czytanie kodu na ekranie lub papierze i / lub wprowadzanie na karcie dziurkacza
    1. wydłuża to czas debugowania
    2. utrudnia to zrozumienie kodu do aktualizacji / konserwacji
    3. może to prowadzić do niezamierzonego powielania kodu
  3. zwiększa to nieco prawdopodobieństwo błędu składniowego
  4. zmniejsza elastyczność kodowania, przez co większość pełnych języków ma wysoce uporządkowaną strukturę i nie ma wielu sposobów na powiedzenie tego samego.
  5. wydłuża czas kodowania i kompilacji
  6. może zająć więcej miejsca.

Pewny poziom szczegółowości jest niezbędny dla jasności, jednak ...

minimalny poziom gadatliwości jest dobry, ponieważ:

  1. ludziom łatwiej jest odczytać i przypisać wartość semantyczną niż kodowi czysto symbolicznemu
  2. W nazwach zmiennych i funkcji ułatwia debugowanie, przenoszenie i obsługę kodu
  3. w operacjach języka podstawowego i słowach kluczowych w złożonych językach prowadzi to do mniejszej liczby niepoprawnych przypisań operacji / słów kluczowych.

Niektóre wspaniałe przykłady zbyt lakoniczny poleceń dla wielu ludzi to stare PODSTAWOWE standbys val(x$), str$(x)i chr$(x)... powrót numer z jej ciąg znaków, powrót na ciąg liczb, a także zwraca pojedynczy znak mający wartość ASCII X jako ciąg znaków.

Lub wskaźnik C / C ++ i operatory referencyjne &oraz w *porównaniu ze byrefsłowem kluczowym BASIC . W C / C ++ mogę mieć zmienną X i przekazać wskaźnik do tej zmiennej, ale muszę pamiętać, który to wskaźnik, a który to „użyj wskaźnika jako zmiennej, na którą wskazuje”; w zasadzie po prostu przekazuję odwołanie słowem kluczowym byref w wywołaniu funkcji, co jest bardziej jasne, ale mniej elastyczne:

def fn Foo(x byref as float) foo= (x += x+1)
...
Foo(x)

W tym kodzie zawartość x jest modyfikowana z powodu flagi byref. Niektóre smaki pozwalają byref na telefon, inne w definicji, niektóre w obu.

Szczegółowość jest ważna dla zwykłych programistów, aby mogli łatwiej korzystać z symboliki; BASIC lub python są bardziej czytelne dla ludzi i bardziej gadatliwe niż C / C ++, a zatem znacznie bardziej przydatne dla zwykłych programistów; zwięzłość C / C ++ sprawia, że ​​jest to znacznie lepsze dla bardziej doświadczonych programistów, którzy muszą zobaczyć więcej kodu i bardziej złożony kod na jednym ekranie, ale musieli nauczyć się różnych konwencji struktury symbolicznej. Na drugim końcu znajduje się APL, który jest prawie całkowicie nieczytelny dla człowieka.

Powiązanym ze sobą problemem jest przejrzystość - zwięzły kod jest często niejasny, a nadmiernie szczegółowy kod (jak w AppleScript) może być równie niejasny. Znajomość danego języka zwiększa przejrzystość zwięzłego kodu w tym języku - surowy początkujący, stojący w obliczu kodu C ++ prawdopodobnie będzie w stanie analizować tylko formuły, a nawet bardzo funkcjonalny kod BASIC lub Python jest zbyt krótki, aby go zrozumieć, ale AppleScript potrafi być zaskoczonym, ogólnie rzecz biorąc, bez uciekania się do słowników językowych. Najmniej jasne, jakie spotkałem bez celowego zaciemniania, to Inform 7 ...

W dawnych czasach

Innym ważnym zagadnieniem w przeszłości, ale tym, które nie jest już tak ważne dla programisty hobbystycznego, jest obsługa i przestrzeń do przechowywania. (W dalszym ciągu jest to niezwykle ważne.) Pamiętając, że zinterpretowano wiele języków, zwłaszcza BASIC, a wiele innych zostało skompilowanych w czasie wykonywania, przestrzeń kodu była ważna, szczególnie gdy dyski miały tylko 128 KB, a pojedyncze karty dziurkaczy tylko 80 B.

Istniało kilka rozwiązań - tokenizacja była niezwykle powszechna w języku BASIC; poszczególne słowa kluczowe w języku zostały zredukowane do 1 lub 2 bajtowego słowa w górnej 128 lub w przestrzeni kontrolnej. Tokenizacja prowadzi również do kompilacji kodu bajtowego (jak w Inform i Z-Machine).

Do obejścia ograniczeń przestrzeni wykorzystano także kompilację i łączenie wielu plików obiektowych. Sekcja kodu Pascal 100 kB może zostać skompilowana tylko do 5 kB; łącząc wiele skompilowanych plików, można budować masywne aplikacje bez dostępu do dysków wielkoformatowych (pamiętając, że 10 MB był zadziwiająco duży, a drogi zakup nowego samochodu).

Jednak więcej zwięzłych języków dostało więcej kodu do danego fragmentu dysku i pamięci RAM, a tym samym skompilowało większe fragmenty naraz. Pamiętając: „minikomputery” z początku lat 70. XX wieku mogły mieć tylko 64 kB pamięci RAM (Honeywell 800 miał podstawową instalację 4 banków po 2048 słów po 8B każdy). APL i podobne języki symboliczne zbliżyły się do 1B na instrukcję plus jej operandy, w porównaniu do znacznie większej 3B-10B na instrukcję plus operandy. (Pisanie na kartach punktowych było koszmarem, zwłaszcza, że ​​symbole były zasadniczo czcionką na typ-ball, a wiele kart nie miało symboli na klawiszach ...)

Pamiętaj też, że kart nie można usunąć ... i wiele programów wprowadzono na kartach. Chociaż nie jest to indywidualnie drogie, im bardziej skompresowany kod może znajdować się na karcie, tym mniej potrzebujesz, i tym większe mogą być programy lub mniej kosztowne. Jest to jeden z powodów, dla których BASIC łączy wiele instrukcji na linię w większości odmian - wprowadzono, aby oszczędzać na kartach poncz. (A przynajmniej tak mówi mój tekst programowania Vax Basic.) Chociaż nie zaprogramowałem czytnika kart, wykonałem wykrawanie kart dla Honeywell 800 w FORTRAN, BASIC, APL i kilku innych wysoce symbolicznych językach.


Szczegółowość w wielu przypadkach zwiększa prawdopodobieństwo wykrycia błędów typograficznych w czasie kompilacji, a nie tylko powoduje błędne zachowanie.
supercat

-1

Podobnie jak w przypadku tak wielu rzeczy, odpowiedź zależy od konkretnej definicji „gadatliwości”. Jeśli definicja jest taka, że ​​gadatliwość oznacza nadmiarowość, to twierdzę, że zawsze jest zła. Zauważ, że przy takiej definicji często cytowany program Java hello world nie kwalifikowałby się jako „pełny”, ponieważ nie ma w nim nic zbędnego.


1
Zrównoważone nawiasy klamrowe i średniki są zbędne, ponieważ w dużej mierze są deklaracjami typu.
Marcin

1
@Marcin: Tak, ale ułatwiają pisanie parsera / analizatora dla języka. Jestem dość przekonany, że taka składnia istnieje na korzyść implementatora języka, a nie programisty używającego tego języka.
ccoakley

1
@Marcin - zależy całkowicie od języka, czy deklaracje typu są, czy nie są potrzebne. Pewne systemy typów po prostu nie są rozstrzygalne, stąd ... w odniesieniu do nawiasów i średników, no cóż, wolisz język z jednoznaczną gramatyką i krótkim wyprzedzeniem - albo kompilowanie nawet małych programów może zająć godziny, a na koniec możesz mam wybór, którą interpretację programu preferujesz.
Ingo

1
@ingo Nie znam żadnego języka, w którym wszystkie zmienne lub funkcje muszą mieć deklarację typu ze względu na złożoność systemu typów. W rzeczywistości powiedziałbym, że języki z mocniejszymi systemami typów częściej pozwalają na pominięcie takich deklaracji.
Marcin

1
@Marcin, nie ma powodu do gniewu. Powiedziałeś , że powiem, że języki z mocniejszymi systemami typów są bardziej skłonne do pominięcia takich deklaracji, i podałem ci przykład, w którym mocniejszy system typów wymaga więcej adnotacji typu. Jeśli uważasz, że nie jest to sprzeczne z twoją postawą, to dobrze, niech tak będzie.
Ingo

-1

Programiści lubią języki z ekspresyjną mocą, ponieważ pozwala im zakodować proste rzeczy, które często muszą być wykonywane często, w małych kawałkach kodu. Pełne języki zwykle oznaczają, że wiele, wiele wierszy kodu musi być używanych do robienia tego samego w kółko. Jednak ekspresywne języki mogą być płatne, ponieważ ich realizacja nie jest tak szybka, jak prostsze języki wysokiego poziomu. Jeśli mogę podać przykład w przeciwieństwie do C i C ++. C ++ daje twórcom kodu bardziej ekspresyjną moc - mogą oni zawrzeć ideę obiektów świata rzeczywistego w klasach. Programiści C mogą osiągnąć te same rzeczy, ale mają ekspresyjną moc konstruktu klasowego, aby im pomóc - tak często muszą pisać dłuższy, bardziej skomplikowany (aby zrozumieć) kod. Ale ten kod może działać szybciej (chociaż jest to wysoce zależne od jakości kompilatora itd.), Ponieważ nie używa „późnego wiązania” C ++ (tj. Refaktoryzacji w czasie wykonywania) do wykonania kodu. C po prostu wykonuje skompilowany i połączony kod, C ++ musi podjąć decyzję (w pewnych okolicznościach) w czasie wykonywania o tym, które fragmenty kodu wykonać.


Przez to „późne wiązanie” prawdopodobnie masz na myśli wirtualne wywołania funkcji. Ale to tylko jeden ze sposobów na wiele innych sposobów na ponowne wykorzystanie kodu. Pisanie dynamiczne jest kolejnym, i prawdopodobnie byłby lepszym przykładem dla twojej sprawy, ponieważ zwykle wiąże się z dużo większym nakładem pracy niż wirtualne wywołania C ++. Ale są też mechanizmy, które w ogóle nie wpływają na wydajność środowiska wykonawczego, ponieważ można je w pełni rozwiązać w czasie kompilacji: we współczesnych językach obiektowych masz szablony / generyczne, w statycznych językach funkcjonalnych polimorfizm parametryczny.
lewo około

Późne wiązanie jest używane do wywołania funkcji wirtualnych, więc nie, nie miałem na myśli „wirtualnych wywołań”, miałem na myśli późne wiązanie. Połączenia wirtualne są częścią definicji języka, późne wiązanie sprawia, że ​​ta część działa. I tak, oczywiście, że istnieją inne przykłady w innych językach, podałem przykład potencjalnego kompromisu między mocą ekspresji a szybkością, nie polecając jednego języka nad drugim.
adrianmcmenamin

-1

Uważam, że odpowiedź na to pytanie jest zakorzeniona w bardziej fundamentalnym i teoretycznym zagadnieniu niż czytelność i ta odpowiedź jest związana z algorytmiczną teorią informacji stworzoną przez Gregory'ego Chaitina: http://en.wikipedia.org/wiki/Al Algorytmic_information_theory . Mówiąc w kilku słowach: „zawartość informacji ciągu znaków odpowiada długości najkrótszej możliwej niezależnej reprezentacji tego ciągu”, oznacza to, że najkrótszy program (mianowicie pod względem długości leksykograficznej) ściśle rozwiązuje dany problem odpowiada wewnętrznej złożoności problemu, któremu daje rozwiązanie, a zatem zależy bardziej od natury problemu, a mniej od reprezentacji problemu.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.