Jakie są zalety wyświetlania numerów wierszy w edytorze tekstu?

27

Czuję się dziwnie, gdy edytuję kod w środowisku IDE, które nie ma numerów wierszy w edytorze tekstu.

Mam pytania:

  1. Czy numery linii są wizualnie nadmierne, szczególnie gdy w twoim IDE istnieje funkcja wyszukiwania według linii?
  2. Jakie są zastosowania wyświetlania numerów linii?
ide Nick Larsen
źródło
35
2: Poczuj się całkowicie jak macho w stosunku do liczby napisanych wierszy kodu.
Adam Crossland,
4
@AdamCrossland: zabawne, że powinieneś wspomnieć, że zwykle uważam to za coś zupełnie przeciwnego i im więcej wierszy kodu piszę, tym więcej czasu spędzam na przeglądaniu go, aby upewnić się, że nic nie zrobiłem dwa razy i że „ m spełniające specyfikację
Nick Larsen,
4
tak, to wszystko dotyczy również mnie, ale czasami trzeba po prostu założyć kask motocyklowy i wybrać macho.
Adam Crossland,
3
Szybciej przewijam numery linii niż korzystam z funkcji linii goto mojego edytora (być może dlatego, że za każdym razem muszę ją znaleźć), zwłaszcza gdy jestem już blisko
maniak zapadkowy
7
@Adam: Poczuj całkowicie Macho, jak mało wierszy kodów napisałem, aby działało.
Newtopian,

Odpowiedzi:

14

Wszystko, co pomaga w komunikacji, to plus.

  1. Nie zajmuje dużo miejsca, więc nie, nie jest nadmierne, jeśli ty lub którykolwiek z twoich kolegów uważa za użyteczne omówienie kodu.

  2. Nawet jeśli nie wykonujesz programowania w parach, przydaje się przy recenzjach kodu „na ramieniu”, jeśli nie korzystasz z narzędzi takich jak Code Collaborator (obecnie tego nie robimy).

Również jeśli masz członków zespołu na innych stronach (my), przydaje się to do omawiania kodu przez komunikator lub przez telefon.

Jak możesz im powiedzieć, żeby poszli do linii 1842, jeśli nie widzisz linii?

Dla mnie jest to nieocenione proste narzędzie. Nawet niektóre nasze specyfikacje pdf mają numerowane linie i to niesamowite, o ile łatwiej jest odwoływać się i dyskutować w porównaniu do tych nienumerowanych.

Hugo
źródło
54

Nikt nie wspominał, że jest w stanie szybko spojrzeć na ślad stosu wyjątku, aby dowiedzieć się, gdzie wystąpił wyjątek.

wałek klonowy
źródło
Naprawdę? Stany OP "referencing stack trace line numbers". Czy oboje macie na myśli różne rzeczy?
StuperUser
3
Ups ... tęskniłem za tym! Cóż ... to ważne, więc warto to powtórzyć! ;)
wałek klonowy
4
Cóż, pytanie zostało już zredagowane, głosuj ahoy!
StuperUser
I oczywiście przeglądanie dzienników (niekoniecznie z wyjątków). Wszystkie nasze dzienniki indeksują plik + linię, z której pochodzą, niezwykle przydatne!
Matthieu M.,
@maple_shaft, Właściwie nawet jeśli nie widzisz linii, nadal możesz Ctrl-G (np. zwykły stary notatnik).
Pacerier
51

Wyświetlane numery linii są niezbędne do programowania w parach. Nie ma szybszego sposobu, aby skierować oczy pary na kod, o którym myślisz.

W związku z tym numery linii są również niezwykle przydatne do przeglądów kodów, zarówno formalnych, jak i nieformalnych.

Eric Wilson
źródło
+1: Nie brałem pod uwagę programowania w parze (choć nie jest to zaskakujące, ponieważ zdecydowanie nie jestem fanem). Jednak przydatność numerów linii w recenzjach kodu jest dość zmieniona, jeśli używasz do tego aplikacji (takiej jak CodeCollaborator)
Demian Brecht,
Nie miałem zwyczaju numerowania linii, dopóki nie wykonałem trochę programowania par, teraz mam zwyczaj numerowania linii. +1 za nakłonienie mnie do zrealizowania tego połączenia.
SingleNegationElimination
11
Zamiast mówić „Linie od 247 do 253” , szybciej podkreślam te linie lub wskazuję je palcem. Nie wydaje mi się, aby ta odpowiedź wystarczała, aby uzasadnić dodatkowy bałagan.
BlueRaja - Danny Pflughoeft
1
Jestem zaskoczony, że ta odpowiedź otrzymała 36 głosów pozytywnych w ciągu 24 godzin.
Eric Wilson,
@BlueRaja: też nie jestem pewien programowania w parach (chociaż możesz mieć obie ręce zajęte), ale podczas dyskusji między biurkami zdecydowanie to pomaga! Jest coś, czego nie rozumiem w yyy.cpp w linii 314, dlaczego tego potrzebujemy?
Matthieu M.
10

  1. Nie, lubię mieć dane, które pozwolą mi zorientować się, gdzie jest coś w pliku, szczególnie jeśli patrzę na duży plik konfiguracyjny, w którym znalezienie tego miejsca może nie być łatwe.

  2. Mogę spojrzeć na numer linii, aby zobaczyć, jak duży jest plik. Jeśli w pliku znajduje się kilka tysięcy wierszy kodu, może być czas zastanowić się, czy plik ten powinien zostać rozbity czy coś. Mogę go również użyć, aby ocenić, jak głęboko jestem w pliku, jeśli mam pole wielkości pliku i jakie liczby są na ekranie. Podoba mi się pomysł określenia mojej lokalizacji na pasku przewijania, np. Jestem w górnej ćwiartce pliku lub 3 kwintylu.

JB King
źródło
1
Kilka tysięcy ?
Anthony Pegram,
4
@Anthony: Powinieneś zobaczyć loc na plik w grze;)
Demian Brecht
3
@Anthony: pewnie. Łatwo widziałem pliki źródłowe z 10k + LOC.
tdammers
1
@tdammers, więc i ja. Problem nie polega na tym, czy te pliki istnieją, jest to moment, w którym należy rozpocząć ponowne rozpatrzenie. Moim zdaniem jest to zwykle na długo przed kilkoma tysiącami. Jest na długo przed kilkuset . W rzeczywistości, kiedy zaczynam przewijać, zaczynam czuć się trochę zaniepokojony (nie oznacza to, że natychmiast refaktoryzuję, pamiętajcie o tym).
Anthony Pegram,
5
@Anthony Pegram - Uważam, że program powinien mieć dobrą strukturę za pomocą funkcji / procedur i tak dalej. Fakt, że wszystkie znajdują się w tym samym pliku, nie przeszkadza mi; wręcz przeciwnie; Wolę je wszystkie zamiast mnóstwa plików w jednym katalogu. Łatwiej też różnicować, IMO.
Wieżowiec
9

Pochodzę z historii używania edytorów z osadzonymi w nich numerami linii. Moje przemyślenia na ten temat? Są absolutnie niepotrzebne (teraz używam Vima z wyłączonymi numerami linii). Pomyśl o tym: Nawet gdy zrobić uzyskać śladów stosu i takie, ile razy pan ręcznie spojrzeć na linii przy użyciu numerów linii w przeciwieństwie do ctrl+g(w większości edytorów Windows) lub :line-numw vim?

Edycja: Oczywiście może być inaczej dla innych, ale 99% czasu używam tego drugiego.

Demian Brecht
źródło
7

Jedna wielka rzecz: jeśli używasz programu Visual Studio lub jakiegoś idea ze składanymi regionami, numery linii dają natychmiastowe wyczucie, jak duży jest obszar bez rozszerzania go. Ponadto, jeśli masz jakieś logowanie, które przekierowuje cię do linii problemu, miło jest nie używać polecenia, gdy linia jest tuż przed tobą.

znak
źródło
3

Z jakiegokolwiek powodu (przychodzi na myśl kompilacja krzyżowa) twój kompilator może nie zostać zintegrowany z twoim IDE. Dlatego potrzebne jest bezwzględne odniesienie do miejsca występowania błędów. (Gdy kompilujesz poza swoim IDE)

NWS

NWS
źródło
2

Jedynie raz użyłem numerów linii, kiedy pojawił się błąd, a ślad stosu mówi mi, że to się stało na linii x.

Widziałem wielu profesjonalnych programistów pracujących bez numerów linii. Tak więc nie widzę innego zastosowania niż późne odwołania .

Saeed Neamati
źródło
2

Lubię to mieć, kiedy używam podzielonego ekranu w jEdit.

Christopher Mahan
źródło
+1 To zdecydowanie pomaga zorientować pracę podzielonego ekranu w tym samym pliku! Istnieje kilka innych sposobów ustalenia, czy przeglądasz odniesienie, czy obszar roboczy pliku.
Adam
1

Tak, jak mówi @maple_host, naprawdę wygodnie jest zrobić plik „vi file.py +142”, gdy widzę wyjątek pochodzący z kodu pod tym numerem wiersza. Plus inne wymienione zalety związane ze sparowanym programowaniem itp. Zawsze warto mieć włączone numery linii w dowolnym edytorze. (Pamiętam niejasny błąd kompilacji zgłoszony przez MS VC ++ 6 w jednym ze standardowych plików nagłówka, linia #blah !! .. To była właściwie redefinicja makra zrobiona przeze mnie !!). Znajdź i zabij.

pozdrowienia, Yati Sagade

yati sagade
źródło