Przewodnik po składaniu kodu dla nie-programistów


13

tło

Byłem autorem artykułu naukowego zawierającego kod, a ostatnio otrzymałem dowody, tj. To, co autorzy pisma stworzyli z mojego rękopisu. Wynik był nie do zaakceptowania: Wcięcie jest niespójne; na końcu każdego bloku kodu znajduje się kropka; cudzysłowy zostały zniszczone itp. Zauważ, że wszystkie błędy nie były specyficzne dla używanego języka programowania.

Teraz rozumiem, dlaczego ktoś, kto nie ma doświadczenia w programowaniu i nie ma zasobów zewnętrznych, popełnia takie błędy, ale w czasach Internetu nikt nie powinien być bez zasobów zewnętrznych. Dlatego skonsultowałem się z moją ulubioną wyszukiwarką, aby znaleźć coś do zasugerowania i znalazłem… nic. Istnieje wiele wskazówek dla programistów, jak pięknie pisać kod w LaTeX lub podobnym, co jest całkiem miłe i właściwe, ale oczywiście nie jest to przeznaczone dla osób, które muszą pisać kod kogoś innego.

Pytanie

Szukam zasobu, który:

  • wyjaśnia podstawy pisania kodu,
  • jest skierowany do składu bez doświadczenia w programowaniu.

Trudność polega na tym, że zależy to od używanego języka i konwencji, więc pytanie jest dość szerokie, nawet jeśli odpowiedzi tylko łączą zasoby
Zach Saucier

2
@ Scott Cóż, jeśli chodzi o cytaty, spacje, znaki - rzeczywiście można całkiem dobrze uogólnić: należy je zachować.
Michaił V

1
@MikhailV Po prostu czuję, że wiele języków kodowych ma więcej wspólnego z językami obcymi niż tylko z wytycznymi. Jasne, że możesz z grubsza określić, gdzie powinny być umieszczone spacje i linie, ale żeby być dokładnym, naprawdę musisz zrozumieć język, w którym się piszesz. Tak, możesz powiedzieć redaktorom / korektorom, aby zostawili „tak jak jest”, co nie znaczy, że ostatecznie będzie to poprawne.
Scott

1
@Wrzlprmft Zabawne, nie można skopiować wklejonego pliku PDF z pythona bez utraty wszystkich poprzedzających białych znaków w programie Acrobat lub Acrobat Reader. „Inteligentnie” je usuwa. Podobnie, jeśli wkleisz kod do wielu edytorów WYSIWYG, takich jak word lub INdesign, zastąpią one cytaty typograficznymi (chyba że wyłączysz taką funkcję), ale dla kodu, który jest rzeczywiście ZŁY. Również w idesign nie można naprawdę poprawnie wpisać kodu bez wprowadzenia innego znaku do łamania linii, co może stać się złą rzeczą, jeśli kiedykolwiek skopiujesz kod z powrotem.
joojaa,

1
@ usr2564301: Po pierwsze, to pytanie jest obecnie wyszukiwane przez niektóre wyszukiwarki, a więc jest bardziej prawdopodobne, że każdy pisarz mający takie same problemy jak mój może znaleźć potencjalną odpowiedź (a jeśli nie, mógłbym być odpowiednio zadowolony z siebie) o tym). Po drugie, tak, w odpowiedzi na moje dowody umieściłem link, ponieważ może to zapobiec błędom, które nie zostały jeszcze popełnione w drugiej rundzie dowodów. Posiadanie referencji również nie szkodzi, jeśli naświetlacz jest uparty. Wreszcie jest to czasopismo / wydawca, które rzadko ma do czynienia z kodem, więc różni się nieco od scenariuszy, które przedstawisz.
Wrzlprmft

Odpowiedzi:


7

Być może chodzi o to, że kod nie powinien być tak naprawdę składany w sposób, w jaki ludzie rozumieją skład. Tak więc, umieszczając kod w dokumencie, należy go umieścić dosłownie , tak jak we wszystkich spacjach, tabulatorach, znakach specjalnych i innych oraz nietkniętych wierszach.

  • Tabulatory powinny mieć szerokość od 4 do 8 spacji (najczęściej cztery)
  • Czcionka powinna być czcionką o stałej szerokości. I prawie powszechnie musi być.
  • Upewnij się, że Twoja aplikacja nie zastępuje!

    To oznacza brak ligatur.

    Również wiele programów (takich jak Word i InDesign) zmienia proste cudzysłowy na pary typografów. Upewnij się, że takie opcje są wyłączone, zanim umieścisz kod w dokumencie.

  • Nie pozwól, aby kod automatycznie przepływał z jednej linii do drugiej. Nie dotykaj kodu, nie jesteś ekspertem!

Kod nie jest tekstem podstawowym, nie jest zgodny z żadnymi konwencjami typograficznymi. Zadaj sobie pytanie, czy chcesz wpisać tekst na ilustracji?

Jeśli jesteś ekspertem

Jeśli jesteś ekspertem i znasz dany język, obowiązują następujące zasady.

Uwaga : Nie zgaduj ani nie wywnioskuj, przeczytaj to, co zostało powiedziane. Wiele języków wygląda tak samo, a kod może być pseudo-językiem, który wygląda jak prawdziwy kod. Następnie możesz:

  • Wykonuj edytor, np. Kolorowanie / pogrubianie / italizowanie słów kluczowych, tylko wtedy, gdy podstawienie ma taką samą stałą szerokość. Najlepiej pozwól edytorowi zrobić to za Ciebie (redaktorzy jak powiedzmy, że scintilla może eksportować sformatowany kod). Pamiętaj, że redaktor musi znać język, być może także biblioteki.

    Uwaga: jeśli zrobisz to źle, spowoduje to więcej szkody niż pożytku.

Jeśli jesteś ekspertem w dziedzinie. Jak w języku i bibliotece i rozumiem kod:

  • Następnie możesz wyrównać kod w kilku wierszach, jeśli nie pasuje do twojego układu. Nie rób tego, chyba że naprawdę wiesz, co robisz, może skończyć się nieodwracalną szkodą.

    Test lakmusowy to czy mógłbyś napisać dany kod. Jeśli nie, to nie możesz osądzać. Zapytaj autora.

    Jak sobie z tym poradzić? Programiści rozumieją standardy stylu kodu. Po prostu napisz w wytycznych przesyłania, że ​​możesz zmieścić tylko X znaków w wierszu. Programiści mogą to zrobić sami. Edytory kodu często mają do tego odpowiednie narzędzia. To kolejny powód, aby używać czcionki o jednolitym odstępie.

Ale wtedy wiedziałeś o tym wszystkim, w końcu byłeś ekspertem. Lepiej pozwól autorowi edytować kod.

Numery linii?

Niektóre języki programowania i przypadki użycia mogą korzystać z numerów linii. Bądź jednak ostrożny, ponieważ w niektórych językach jest to faux pas .

Problemy

Pamiętaj, że bez względu na to, co robisz, możesz rzeczywiście stawić czoła niemożliwym przeszkodom technicznym. Kod nie powinien być tak naprawdę składany, powinien być po prostu niesformatowanym tekstem. Prowadzi to do zaskakujących problemów.

Na przykład: Języki takie jak Python nie mogą być obsługiwane przez wiele przeglądarek PDF, takich jak Adobe Acrobat. Jeśli wkleisz kod z pliku PDF, edytor postanowi nie dołączać poprzedniej spacji podczas wklejania kopii. To niszczy możliwość wklejenia kodu z pliku PDF do edytora. Naprawdę nie ma dobrego sposobu na poradzenie sobie z tym!


@ usr2564301 ah tak so true
joojaa

1
@ usr2564301 Zrobione, w każdym razie myślę, że czytelny wybór czcionek jest czymś, co typograf powinien zrozumieć. W każdym razie taki, który rozróżnia małe litery i bez kropki (tak, debugowaliśmy jeden kawałek kodu przez miesiąc, ponieważ nie wiedzieliśmy, że małe „i” różni się od wielkich „I” w języku tureckim) tworzą 1 też
joojaa,

„Nie pozwól, aby kod przepływał z jednego wiersza do drugiego” to dobra rada w teorii. Ale jeśli składasz standardowy format wydruku 6x9 i masz linię kodu z 600 znakami, trudno będzie ci się zorientować.
Janus Bahs Jacquet

1
@JanusBahsJacquet Kod jest zwykle pisany mniej niż 80 znaków w wierszu. Więc jeśli dostaniesz coś takiego, być może twoje wytyczne dotyczące przesyłania są do kitu. Programiści wiedzą o wytycznych dotyczących przesyłania, w końcu to są podstawy kodowania. Rzecz w tym, że przerywając linie, możesz skończyć ze zmianą znaczenia kodu.
joojaa,

1
@JanusBahsJacquet Dlatego pytasz autora, aktualizujesz wytyczne, więc nie musisz robić tego zbyt często. cóż, w obu przypadkach, jeśli kod nie może być podzielony z długich linii, wówczas składarka nie może nic z tym zrobić. Nawiasem mówiąc, co zrobiłby na maszynie zbyt szeroki obraz, którego nie można zmienić rozmiaru ani przyciąć? W każdym razie przewiduję, że przesyłanie kodu będzie bardziej powszechne w przyszłości
joojaa,

4

Odpowiedź może oczywiście zależeć od wielu czynników, ale jeśli zaczniemy od poprawnego, dobrze sformatowanego kodu w postaci zwykłego tekstu , można tutaj mniej więcej uogólnić.

Początkowe „formatowanie” w tekście źródłowym to: znak nowej linii , spacja i tabulator . Zauważ, że nowa linia i ręczne łamanie linii (jak w oprogramowaniu DTP) to nie to samo i odwrotnie, niektóre rzadkie języki mogą dopuszczać inne znaki formatujące, chociaż nigdy o nich nie słyszałem.

Komentarze nie są wykonywalną częścią kodu, więc można je sformatować bez większego ryzyka, jeśli wiadomo, czy to naprawdę komentarz. Pierwszą rzeczą do obejrzenia jest sposób oznaczania komentarzy.

Warto zapoznać się z podstawami formatowania tekstu jawnego. Np. W przypadku Pythona istnieje przewodnik po stylu PEP8 . Ten podręcznik formatowania, stworzony dla języka Python, może służyć jako odniesienie dla głównych języków, takich jak C / C ++ i Java. W razie wątpliwości pomocne mogą być różne przykładowe projekty.

Zatem pierwsza zasada brzmi: nie zmieniaj tekstu źródłowego. Przejrzałbym listę kontrolną - upewnij się, że:

  • Na żadnym etapie nie występuje automatyczne zastępowanie znaków .
  • Nie wprowadza się żadnych zmian w tekście (chyba że masz 100% pewności, że należy to zrobić).
  • Nie pojawiają się zawijania linii.
  • Wcięcia są zachowywane wizualnie i są spójne (około cztery x  szerokości na poziom wcięcia).
  • Początkowy (zerowy) poziom wcięcia powinien być widoczny.
  • Zdefiniowane style nie niszczą formatowania składni (jeśli zastosowano podświetlanie składni).
  • Wykonaj kopię zapasową źródła w postaci zwykłego tekstu, aby móc ponownie sprawdzić oryginalne formatowanie lub rozpocząć od nowa.
  • Numery linii, jeśli są obecne, powinny pozostać nienaruszone, szczególnie jeśli podano je w objaśnieniach.

W rzeczywistości, jeśli oryginalne źródło jest poprawnie sformatowane, nie powinno być żadnego zawijania linii. Jeśli owinięte linie nadal się pojawiają i są nieuniknione, wówczas najczęściej stosowanym rozwiązaniem jest zawieszenie na jednym poziomie (patrz powyżej połączony PEP). Jeśli konieczne jest łamanie linii - lepiej skonsultuj się z przewodnikiem po stylu lub autorem.

Nadal niektóre niewielkie znaki „białych znaków” mogą wymagać wymiany. Ponieważ źródło może zawierać znaki tabulacji, oznacza to oczywiście, że składarka musi upewnić się, że wszystkie tabulatory na początku każdej linii są spójne, tj. Zagnieżdżone wcięcia są zachowywane wizualnie, a każdy kolejny poziom wcięcia ma tę samą szerokość (około cztery x  szerokości na jeden poziom wcięcia).

Najlepiej byłoby, gdyby wcięcia wykonane za pomocą znaków spacji lub mieszanych spacji i tabulatorów zostały zastąpione tabelą (lub tym, co oprogramowanie DTP może zrobić lepiej dla zagnieżdżonych wcięć), więc w razie potrzeby dostosowanie wcięć może być łatwiejsze.
Oczywiście można zostawić spacje, ale trudniej jest zarządzać ich szerokością podczas zmiany czcionki i trudniej wyrównać wcięcia w linii wewnętrznej, jak w kolumnach tabeli.

Czcionka o stałej szerokości + spacje

Zauważ, że jeśli źródło jest celowo formatowane spacjami i miało być odczytywane tylko czcionką o stałej szerokości (na przykład diagramy ASCII lub grafika ASCII), należy zachować spacje całkowicie niezmienione , ale decyzję tę należy podjąć od samego początku. Czcionka „Courier New” jest najczęściej stosowana w tym przypadku. Mimo to, jeśli nie jest to naprawdę potrzebne, odradzam monospaced, ponieważ coraz mniej nowych osób wybiera dzisiaj monospaced do kodowania, aw przypadku korekty proporcjonalne czcionki zapewnią lepsze czytanie.

Ogólnie rzecz biorąc, skondensowane (np. Wąskie Arial) lub mniejsze czcionki mogą działać lepiej: daje większy nacisk w przeciwieństwie do tekstu podstawowego, sprawi, że kod będzie bardziej zwarty, a zatem mniej prawdopodobne, że pojawi się niepożądane zawijanie linii.

Myślę, że tutaj można narysować linię, a jeśli powyższe zostanie zrobione, istnieje 99% prawdopodobieństwo, że wszystko powinno być w porządku, przynajmniej dla zwykłego bloku kodu z pojedynczą czcionką bez kolorów.


Narzędzia i zaawansowane formatowanie

Ponadto wygląd można znacznie poprawić, używając podświetlania składni.

  • kolorowy wydruk lub podgląd ekranu: w układzie pełnego koloru można użyć każdej funkcji wyróżniania, więc jest to najlepszy scenariusz, ale drukowanie może powodować pewne zmiany kolorów.

  • skala szarości lub druk czarno-biały: tutaj oczywiście można użyć pogrubienia (np. słowa kluczowe) lub kursywy (np. komentarze), ale należy pamiętać, że kolory zostaną zamienione na szary ze wszystkimi konsekwencjami. Na przykład szare komentarze mogą wyglądać świetnie na wyświetlaczu, ale na papierze mogą być zbyt blade.

Najważniejsze pytanie dotyczy tego, czy twórca układu ma narzędzia, które mogą reprezentować kod w czytelnej formie. Na szczęście istnieje wiele bezpłatnych narzędzi do edycji kodu, z których najważniejsze (dla Windows) to: Notepad ++, VSCode, Visual Studio . Pamiętaj jednak o możliwej niejawnej automatycznej konwersji tabulatorów na spacje.

W Notepad ++ istnieje opcja eksportu kodu jako RTF , który zachowa całe formatowanie i podświetlanie składni źródła.

Jeśli układ nie wymaga zmiany przepływu tekstu w prezentacji kodu, można bezpośrednio użyć obrazów (zrzutów ekranu) - nie jest tak elastyczny jak tekst, ale zachowa 100% formatowanie i numerację linii i może zaoszczędzić dużo czasu. Np. Numery linii mogą być trudne do zachowania w formie tekstowej. Również eksport do formatu PDF jest dobrą alternatywą - ale nie wszystkie programy DTP mogą osadzać pliki PDF, a niektóre formatowanie może zostać utracone podczas drukowania do formatu PDF.

Na przykład moja konfiguracja kodu Python w Notepad ++ wygląda następująco:
wprowadź opis zdjęcia tutaj

To tylko dla zilustrowania, że ​​można bezpośrednio używać zrzutów ekranu i może to być najłatwiejsza metoda. Istnieją różne narzędzia, które mogą pomóc w przechwytywaniu ekranu - może być konieczne „zszycie” ekranów w celu uzyskania obrazów o wyższej rozdzielczości.

Kolorystyka jest oczywiście indywidualna, zdefiniowana w konfiguratorze stylów edytora, który jest już świadomy obsługiwanego języka, co utrudnia fałszywe formatowanie, nawet jeśli nie znamy składni. Tutaj powinny działać ogólne zasady typografii: niezbyt wiele kolorów, spójne czcionki, wcięcia, wygodne odstępy między wierszami.

Dodatkowe narzędzia / wtyczki do niestandardowych definicji języka są również powszechne, ale wymagają znajomości składni.


To wspaniała i przemyślana odpowiedź. Zrzuty ekranu mogą być jednak nieoptymalne, jeśli planujesz wydrukować to ze względu na rozdzielczość. O czym należy pamiętać.
Jeremy Carlson,

1
@JeremyCarlson w Np ++ można również dopasować rozmiar czcionki / odstępy między wierszami - więc teoretycznie nie ma limitu rozdzielczości zrzutu ekranu, ale trudniej będzie go utworzyć, szczególnie na małym ekranie. Może być nawet sztuczka z użyciem wirtualnego wyświetlacza i ustawiania bardzo dużego rozmiaru okna
Michaił V

ponieważ coraz mniej nowych ludzi wybiera dziś kodowanie jednoprzestrzenne - być może, ale ogromna większość wciąż korzysta z tej funkcji. Nie można po prostu tłumaczyć normalnych konwencji składu na kod. Na przykład znaki interpunkcyjne są ważniejsze niż w zwykłych tekstach (większość moich argumentów z tej odpowiedzi przekłada się na to). Krój pisma innego niż monospace różni się znacznie od zwykłego tekstu. Ponadto często chcesz, aby niektóre podobne struktury były wyrównane w poziomie, np . a[i][j] = 1a[m][n] = 2.
Wrzlprmft

@Wrzlprmft dzięki za zmiany. I tak, nie ma tak wielu dobrych czcionek zoptymalizowanych pod kątem kodu i matematyki (Verdana jest w porządku). Rzeczywiście, Times ma niewielką kropkę, dwukropek i kilka innych problemów, ale używam go przez cały czas - „korzyści przewyższają koszty”
Michaił V

-5

W HTML znajduje się zestaw tagów <code> ... </code>, który mówi czytelnikowi / tłumaczowi, aby traktował treść absolutnie dosłownie. również <pre> ... </pre> robi to samo. Jako ktoś, kto często musiał składać formuły, równania i kod do publikacji, zalecam również użycie OBRAZÓW do zrobienia tego ... zrób .gif lub .jpg lub .png problematycznego elementu.

Innym czynnikiem jest to, że kod jest tradycyjnie renderowany w czcionce Courier lub innej czcionce o stałej szerokości, ponieważ semaforuje lub telegrafuje do czytelnika, że ​​nie jest to tekst podstawowy. Popieram ten wybór stylu, myślę, że ma to sens.

W większości „starszych” systemów składu równania matematyczne o dość wysokiej złożoności były wyjątkowo czasochłonne ... i obarczone błędem.


oczywiście obrazów nie można wycinać ani wklejać!
dwoz

3
Nie rozumiem, jak w ogóle odpowiada to pytanie
Zach Saucier,
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.