rozwiń
rozwiń
zwiń
zwiń
wpisz minimum 3 znaki
Czysty kod Podręcznik dobrego programisty
ocena: 6, głosów: 19
 
powiększenie

Fragmenty

przeczytaj fragment książki
Czysty kod Podręcznik dobrego programisty

NIEWIELE JEST RZECZY TAK POMOCNYCH, jak dobrze umieszczony komentarz. Jednocześnie nic tak nie zaciemnia modułu, jak kilka zbyt dogmatycznych komentarzy. Nic nie jest tak szkodliwe, jak stary komentarz szerzący kłamstwa i dezinformację.
Komentarze nie są jak „Lista Schindlera”. Nie są one „czystym dobrem”. W rzeczywistości komentarze są w najlepszym przypadku koniecznym złem. Jeżeli nasz język programowania jest wystarczająco ekspresyjny lub mamy wystarczający talent, by wykorzystywać ten język, aby wyrażać nasze zamierzenia, nie będziemy potrzebować zbyt wielu komentarzy.
Prawidłowe zastosowanie komentarzy jest kompensowaniem naszych błędów przy tworzeniu kodu. Proszę zwrócić uwagę, że użyłem słowa błąd. Dokładnie to miałem na myśli. Obecność komentarzy zawsze sygnalizuje nieporadność programisty. Musimy korzystać z nich, ponieważ nie zawsze wiemy, jak wyrazić nasze intencje bez ich użycia, ale ich obecność nie jest powodem do świętowania.
Gdy uznamy, że konieczne jest napisanie komentarza, należy pomyśleć, czy nie istnieje sposób na wyrażenie tego samego w kodzie. Za każdym razem, gdy wyrazimy to samo za pomocą kodu, powinniśmy odczuwać satysfakcję. Za każdym razem, gdy piszemy komentarz, powinniśmy poczuć smak porażki.
Dlaczego jestem tak przeciwny komentarzom? Ponieważ one kłamią. Nie zawsze, nie rozmyślnie, ale nader często. Im starsze są komentarze, tym większe prawdopodobieństwo, że są po prostu błędne. Powód jest prosty. Programiści nie są w stanie utrzymywać ich aktualności.
Kod zmienia się i ewoluuje. Jego fragmenty są przenoszone w różne miejsca. Fragmenty te są rozdzielane, odtwarzane i ponownie łączone. Niestety, komentarze nie zawsze za nimi podążają — nie zawsze mogą być przenoszone. Zbyt często komentarze są odłączane od kodu, który opisują, i stają się osieroconymi notatkami o stale zmniejszającej się dokładności. Dla przykładu warto spojrzeć, co się stało z komentarzem i wierszem,
którego dotyczył:

MockRequest request;
private final String HTTP_DATE_REGEXP =
"[SMTWF][a-z]{2}\\,\\s[0-9]{2}\\s[JFMASOND][a-z]{2}\\s"+
"[0-9]{4}\\s[0-9]{2}\\:[0-9]{2}\\:[0-9]{2}\\sGMT";
private Response response;
private FitNesseContext context;
private FileResponder responder;
private Locale saveLocale;
// Przykład: "Tue, 02 Apr 2003 22:18:49 GMT"

Pozostałe zmienne instancyjne zostały prawdopodobnie później dodane pomiędzy stałą HTTP_􀂴DATE_REGEXP a objaśniającym ją komentarzem.
Można oczywiście stwierdzić, że programiści powinni być na tyle zdyscyplinowani, aby utrzymywać komentarze w należytym stanie. Zgadzam się, powinni. Wolałbym jednak, aby poświęcona na to energia została spożytkowana na zapewnienie takiej precyzji i wyrazistości kodu, by komentarze okazały się zbędne.
Niedokładne komentarze są znacznie gorsze niż ich brak. Kłamią i wprowadzają w błąd. Powodują powstanie oczekiwań, które nigdy nie są spełnione. Definiują stare zasady, które nie są już potrzebne lub nie powinny być stosowane.
Prawda znajduje się w jednym miejscu: w kodzie. Jedynie kod może niezawodnie przedstawić to, co realizuje. Jest jedynym źródłem naprawdę dokładnych informacji. Dlatego choć komentarze są czasami niezbędne, poświęcimy sporą ilość energii na zminimalizowanie ich liczby.

Komentarze nie są szminką dla złego kodu

Jednym z często spotykanych powodów pisania komentarzy jest nieudany kod. Napisaliśmy moduł i zauważamy, że jest źle zorganizowany. Wiemy, że jest chaotyczny. Mówimy wówczas: „Hm, będzie lepiej, jak go skomentuję”. Nie! Lepiej go poprawić!
Precyzyjny i czytelny kod z małą liczbą komentarzy jest o wiele lepszy niż zabałaganiony i złożony kod z mnóstwem komentarzy. Zamiast spędzać czas na pisaniu kodu wyjaśniającego bałagan, jaki zrobiliśmy, warto poświęcić czas na posprzątanie tego bałaganu.

Czytelny kod nie wymaga komentarzy

W wielu przypadkach kod mógłby zupełnie obejść się bez komentarzy, a jednak programiści wolą umieścić w nim komentarz, zamiast zawrzeć objaśnienia w samym kodzie. Spójrzmy na poniższy przykład. Co wolelibyśmy zobaczyć? To:

// Sprawdzenie, czy pracownik ma prawo do wszystkich korzyści
if ((employee.flags & HOURLY_FLAG) && (employee.age > 65))

czy to:

if (employee.isEligibleForFullBenefits())

Przeznaczenie tego kodu jest jasne po kilku sekundach myślenia. W wielu przypadkach jest to wyłącznie kwestia utworzenia funkcji, która wyraża to samo co komentarz, jaki chcemy napisać.

Dobre komentarze

Czasami komentarze są niezbędne lub bardzo przydatne. Przedstawimy kilka przypadków, w których uznaliśmy, że warto poświęcić im czas. Należy jednak pamiętać, że naprawdę dobry komentarz to taki, dla którego znaleźliśmy powód, aby go nie pisać.

Komentarze prawne

Korporacyjne standardy kodowania czasami wymuszają na nas pisanie pewnych komentarzy z powodów prawnych. Na przykład informacje o prawach autorskich są niezbędnym elementem umieszczanym w komentarzu na początku każdego pliku źródłowego.
Przykładem może być standardowy komentarz, jaki umieszczaliśmy na początku każdego pliku źródłowego w FitNesse. Na szczęście nasze środowisko IDE ukrywa te komentarze przez ich automatyczne zwinięcie.

// Copyright (C) 2003,2004,2005 by Object Mentor, Inc. All rights reserved.
// Released under the terms of the GNU General Public License version 2 or later.

Tego typu komentarze nie powinny być wielkości umów lub kodeksów. Tam, gdzie to możliwe, warto odwoływać się do standardowych licencji lub zewnętrznych dokumentów, a nie umieszczać w komentarzu wszystkich zasad i warunków.

Komentarze informacyjne

Czasami przydatne jest umieszczenie w komentarzu podstawowych informacji. Na przykład w poniższym komentarzu objaśniamy wartość zwracaną przez metodę abstrakcyjną.

// Zwraca testowany obiekt Responder.
protected abstract Responder responderInstance();

Komentarze tego typu są czasami przydatne, ale tam, gdzie to możliwe, lepiej jest skorzystać z nazwy funkcji do przekazania informacji. Na przykład w tym przypadku komentarz może stać się niepotrzebny, jeżeli zmienimy nazwę funkcji: responderBeingTested.
Poniżej mamy nieco lepszy przypadek:

// Dopasowywany format kk:mm:ss EEE, MMM dd, yyyy
Pattern timeMatcher = Pattern.compile(
"\\d*:\\d*:\\d* \\w*, \\w* \\d*, \\d*");

W tym przypadku komentarze pozwalają nam poinformować, że użyte wyrażenie regularne ma dopasować czas i datę sformatowane za pomocą funkcji SimpleDateFormat.format z użyciem zdefiniowanego formatu. Nadal lepiej jest przenieść kod do specjalnej klasy pozwalającej na konwertowanie formatów daty i czasu. Po tej operacji komentarz najprawdopodobniej stanie się zbędny.

Wyjaśnianie zamierzeń

W niektórych przypadkach komentarze zawierają informacje nie tylko o implementacji, ale także o powodach podjęcia danej decyzji. W poniższym przypadku widzimy interesującą decyzję udokumentowaną w postaci komentarza. Przy porównywaniu obiektów autor zdecydował o tym, że obiekty jego klasy będą po posortowaniu wyżej niż obiekty pozostałych klas.

public int compareTo(Object o)
{
if(o instanceof WikiPagePath)
{
WikiPagePath p = (WikiPagePath) o;
String compressedName = StringUtil.join(names, "");
String compressedArgumentName = StringUtil.join(p.names, "");
return compressedName.compareTo(compressedArgumentName);
}
return 1; // Jesteśmy więksi, ponieważ jesteśmy właściwego typu.
}

Poniżej pokazany jest lepszy przykład. Możemy nie zgadzać się z rozwiązaniem tego problemu przez programistę, ale przynajmniej wiemy, co próbował zrobić.

public void testConcurrentAddWidgets() throws Exception {
WidgetBuilder widgetBuilder =
new WidgetBuilder(new Class[]{BoldWidget.class});
String text = "'''bold text'''";
ParentWidget parent =
new BoldWidget(new MockWidgetRoot(), "'''bold text'''");
AtomicBoolean failFlag = new AtomicBoolean();
failFlag.set(false);
//Jest to nasza próba uzyskania wyścigu
//przez utworzenie dużej liczby wątków.
for (int i = 0; i < 25000; i++) {
WidgetBuilderThread widgetBuilderThread =
new WidgetBuilderThread(widgetBuilder, text, parent, failFlag);
Thread thread = new Thread(widgetBuilderThread);
thread.start();
}
assertEquals(false, failFlag.get());
}

Wyjaśnianie

Czasami przydatne jest wytłumaczenie znaczenia niejasnych argumentów lub zwracanych wartości. Zwykle lepiej jest znaleźć sposób na to, by ten argument lub zwracana wartość były bardziej czytelne, ale jeżeli są one częścią biblioteki standardowej lub kodu, którego nie możemy zmieniać, to wyjaśnienia w komentarzach mogą być użyteczne.

public void testCompareTo() throws Exception
{
WikiPagePath a = PathParser.parse("PageA");
WikiPagePath ab = PathParser.parse("PageA.PageB");
WikiPagePath b = PathParser.parse("PageB");
WikiPagePath aa = PathParser.parse("PageA.PageA");
WikiPagePath bb = PathParser.parse("PageB.PageB");
WikiPagePath ba = PathParser.parse("PageB.PageA");
assertTrue(a.compareTo(a) == 0); // a == a
assertTrue(a.compareTo(b) != 0); // a != b
assertTrue(ab.compareTo(ab) == 0); // ab == ab
assertTrue(a.compareTo(b) == -1); // a < b
assertTrue(aa.compareTo(ab) == -1); // aa < ab
assertTrue(ba.compareTo(bb) == -1); // ba < bb
assertTrue(b.compareTo(a) == 1); // b > a
assertTrue(ab.compareTo(aa) == 1); // ab > aa
assertTrue(bb.compareTo(ba) == 1); // bb > ba
}

Istnieje oczywiście spore ryzyko, że komentarze objaśniające są nieprawidłowe. Warto przeanalizować poprzedni przykład i zobaczyć, jak trudno jest sprawdzić, czy są one prawidłowe. Wyjaśnia to, dlaczego niezbędne są objaśnienia i dlaczego są one ryzykowne. Tak więc przed napisaniem tego typu komentarzy należy sprawdzić, czy nie istnieje lepszy sposób, a następnie poświęcić im więcej uwagi, aby były precyzyjne.

Ostrzeżenia o konsekwencjach

Komentarze mogą również służyć do ostrzegania innych programistów o określonych konsekwencjach. Poniższy komentarz wyjaśnia, dlaczego przypadek testowy jest wyłączony:

// Nie uruchamiaj, chyba że masz nieco czasu do zagospodarowania.
public void _testWithReallyBigFile()
{
writeLinesToFile(10000000);
response.setBody(testFile);
response.readyToSend(this);
String responseString = output.toString();
assertSubString("Content-Length:
􀂴1000000000", responseString);
assertTrue(bytesSent > 1000000000);
}

Obecnie oczywiście wyłączamy przypadek testowy przez użycie atrybutu @Ignore z odpowiednim tekstem wyjaśniającym. @Ignore("Zajmuje zbyt dużo czasu"). Jednak w czasach przed JUnit 4 umieszczenie podkreślenia przed nazwą metody było często stosowaną konwencją. Komentarz, choć nonszalancki, dosyć dobrze wskazuje powód.
Poniżej pokazany jest inny przykład:

public static SimpleDateFormat makeStandardHttpDateFormat()
{
//SimpleDateFormat nie jest bezpieczna dla wątków,
//więc musimy każdy obiekt tworzyć niezależnie.
SimpleDateFormat df = new SimpleDateFormat("EEE, dd MMM yyyy HH:mm:ss z");
df.setTimeZone(TimeZone.getTimeZone("GMT"));
return df;
}

Można narzekać, że istnieją lepsze sposoby rozwiązania tego problemu. Mogę się z tym zgodzić. Jednak zastosowany tu komentarz jest całkiem rozsądny. Może on powstrzymać nadgorliwego programistę przed użyciem statycznego inicjalizera dla zapewnienia lepszej wydajności.

Komentarze TODO

Czasami dobrym pomysłem jest pozostawianie notatek „do zrobienia” w postaci komentarzy //TODO. W zamieszczonym poniżej przypadku komentarz TODO wyjaśnia, dlaczego funkcja ma zdegenerowaną implementację i jaka powinna być jej przyszłość.

//TODO-MdM Nie jest potrzebna.
// Oczekujemy, że zostanie usunięta po pobraniu modelu.
protected VersionInfo makeVersion() throws Exception
{
return null;
}

Komentarze TODO oznaczają zadania, które według programisty powinny być wykonane, ale z pewnego powodu nie można tego zrobić od razu. Może to być przypomnienie o konieczności usunięcia przestarzałej funkcji lub prośba do innej osoby o zajęcie się problemem. Może to być żądanie, aby ktoś pomyślał o nadaniu lepszej nazwy, lub przypomnienie o konieczności wprowadzenia zmiany zależnej od planowanego zdarzenia. Niezależnie od tego, czym jest TODO, nie może to być wymówka dla pozostawienia złego kodu w systemie.
Obecnie wiele dobrych IDE zapewnia specjalne funkcje lokalizujące wszystkie komentarze TODO, więc jest mało prawdopodobne, aby zostały zgubione. Nadal jednak nie jest korzystne, by kod był nafaszerowany komentarzami TODO. Należy więc regularnie je przeglądać i eliminować wszystkie, które się da.

Wzmocnienie

Komentarz może być użyty do wzmocnienia wagi operacji, która w przeciwnym razie może wydawać się niekonsekwencją.

String listItemContent = match.group(3).trim();
// Wywołanie trim jest naprawdę ważne. Usuwa początkowe
// spacje, które mogą spowodować, że element będzie
// rozpoznany jako kolejna lista.
new ListItemWidget(this, listItemContent, this.level + 1);
return buildList(text.substring(match.end()));

Komentarze Javadoc w publicznym API

Nie ma nic bardziej pomocnego i satysfakcjonującego, jak dobrze opisane publiczne API. Przykładem tego może być standardowa biblioteka Java. Bez niej pisanie programów Java byłoby trudne, o ile nie niemożliwe.
Jeżeli piszemy publiczne API, to niezbędne jest napisanie dla niego dobrej dokumentacji Javadoc. Jednak należy pamiętać o pozostałych poradach z tego rozdziału. Komentarze Javadoc mogą być równie mylące, nie na miejscu i nieszczere jak wszystkie inne komentarze.

Złe komentarze

Do tej kategorii należy większość komentarzy. Zwykle są to podpory złego kodu lub wymówki albo uzasadnienie niewystarczających decyzji znaczące niewiele więcej niż dyskusja programisty ze sobą.

Bełkot

Pisanie komentarza tylko dlatego, że czujemy, iż powinien być napisany lub też że wymaga tego proces, jest błędem. Jeżeli decydujemy się na napisanie komentarza, musimy poświęcić nieco czasu na upewnienie się, że jest to najlepszy komentarz, jaki mogliśmy napisać.
Poniżej zamieszczony jest przykład znaleziony w FitNesse. Komentarz był faktycznie przydatny. Jednak autor śpieszył się lub nie poświęcił mu zbyt wiele uwagi. Bełkot, który po sobie zostawił, stanowi nie lada zagadkę:

public void loadProperties()
{
try
{
String propertiesPath = propertiesLocation + "/" + PROPERTIES_FILE;
FileInputStream propertiesStream = new FileInputStream(propertiesPath);
loadedProperties.load(propertiesStream);
}
catch(IOException e)
{
// Brak plików właściwości oznacza załadowanie wszystkich wartości domyślnych.
}
}

Co oznacza komentarz w bloku catch? Jasne jest, że znaczy on coś dla autora, ale znaczenie to nie zostało dobrze wyartykułowane. Jeżeli otrzymamy wyjątek IOException, najwyraźniej oznacza to brak pliku właściwości, a w takim przypadku ładowane są wszystkie wartości domyślne. Jednak kto ładuje te wartości domyślne? Czy były załadowane przed wywołaniem loadProperties.load? Czy też loadProperties.load przechwytuje wyjątek, ładuje wartości domyślne i przekazuje nam wyjątek do zignorowania? A może loadProperties.load ładuje wszystkie wartości domyślne przed próbą załadowania pliku? Czy autor próbował usprawiedliwić przed samym sobą fakt, że pozostawił pusty blok catch? Być może — ta możliwość jest nieco przerażająca — autor próbował powiedzieć sobie, że powinien wrócić w to miejsce i napisać kod ładujący wartości domyślne.
Jedynym sposobem, aby się tego dowiedzieć, jest przeanalizowanie kodu z innych części systemu i sprawdzenie, co się w nich dzieje. Wszystkie komentarze, które wymuszają zaglądanie do innych modułów w celu ich zrozumienia, nie są warte bitów, które zajmują.

Powtarzające się komentarze

Na listingu 4.1 zamieszczona jest prosta funkcja z komentarzem w nagłówku, który jest całkowicie zbędny. Prawdopodobnie dłużej zajmuje przeczytanie komentarza niż samego kodu.

LISTING 4 . 1 . waitForClose
// Metoda użytkowa kończąca pracę, gdy this.closed ma wartość true. Zgłasza wyjątek,
// jeżeli przekroczony zostanie czas oczekiwania.
public synchronized void waitForClose(final long timeoutMillis)
throws Exception
{
if(!closed)
{
wait(timeoutMillis);
if(!closed)
throw new Exception("MockResponseSender could not be closed");
}
}

Czemu służy ten komentarz? Przecież nie niesie więcej informacji niż sam kod. Nie uzasadnia on kodu, nie przedstawia zamierzeń ani przyczyn. Nie jest łatwiejszy do czytania od samego kodu.
W rzeczywistości jest mniej precyzyjny niż kod i wymusza na czytelniku zaakceptowanie braku precyzji w imię prawdziwego zrozumienia. Jest on podobny do paplania sprzedawcy używanych samochodów, który zapewnia, że nie musisz zaglądać pod maskę.
Spójrzmy teraz na legion bezużytecznych i nadmiarowych komentarzy Javadoc pobranych z programu Tomcat i zamieszczonych na listingu 4.2. Komentarze te mają za zadanie wyłącznie zaciemnić i popsuć kod. Nie mają one żadnej wartości dokumentującej. Co gorsza, pokazałem tutaj tylko kilka pierwszych. W tym module znajduje się znacznie więcej takich komentarzy.

L I S T ING 4 . 2 . ContainerBase.java (Tomcat)
public abstract class ContainerBase
implements Container, Lifecycle, Pipeline,
MBeanRegistration, Serializable {
/**
* The processor delay for this component.
*/
protected int backgroundProcessorDelay = -1;
/**
* The lifecycle event support for this component.
*/
protected LifecycleSupport lifecycle =
new LifecycleSupport(this);
/**
* The container event listeners for this Container.
*/
protected ArrayList listeners = new ArrayList();
/**
* The Loader implementation with which this Container is
* associated.
*/
protected Loader loader = null;
/**
* The Logger implementation with which this Container is
* associated.
*/
protected Log logger = null;
/**
* Associated logger name.
*/
protected String logName = null;
/**
* The Manager implementation with which this Container is
* associated.
*/
protected Manager manager = null;
/**
* The cluster with which this Container is associated.
*/
protected Cluster cluster = null;
/**
* The human-readable name of this Container.
*/
protected String name = null;
/**
* The parent Container to which this Container is a child.
*/
protected Container parent = null;
/**
* The parent class loader to be configured when we install a
* Loader.
*/
protected ClassLoader parentClassLoader = null;
/**
* The Pipeline object with which this Container is
* associated.
*/
protected Pipeline pipeline = new StandardPipeline(this);
/**
* The Realm with which this Container is associated.
*/
protected Realm realm = null;
/**
* The resources DirContext object with which this Container
* is associated.
*/
protected DirContext resources = null;

Mylące komentarze

Czasami pomimo najlepszych intencji programista zapisuje w komentarzu nieprecyzyjne zdania. Wróćmy na moment do nadmiarowego, ale również nieco mylącego komentarza zamieszczonego na listingu 4.1.
Czy Czytelnik zauważył, w czym ten komentarz jest mylący? Metoda ta nie kończy się, gdy this.closed ma wartość true. Kończy się ona, jeżeli this.closed ma wartość true; w przeciwnym razie czeka określony czas, a następnie zgłasza wyjątek, jeżeli this.closed nadal nie ma wartości true.
Ta subtelna dezinformacja umieszczona w komentarzu, który czyta się trudniej niż sam kod, może spowodować, że inny programista naiwnie wywoła tę funkcję, oczekując, że zakończy się od razu, gdy this.closed przyjmie wartość true. Ten biedny programista może zorientować się, o co
chodzi, dopiero w sesji debugera, gdy będzie próbował zorientować się, dlaczego jego kod działa tak powoli.

Czysty kod
Podręcznik dobrego programisty (miękka)

książka

Wydawnictwo: Helion

Oprawa: miękka

Ilość stron: 424

Wysyłamy w: 24h - 48h + czas dostawy

Nasza cena: 55,89

Cena detaliczna: 64,24

U nas taniej o 13%

dodaj do przechowalni dodaj do listy życzeń Dodaj do koszyka

Przy zakupie 5 egz.
Cena hurtowa:

51,39

Powrót Darmowa wysyłka dla zamówień od 99zł. SPRAWDŹ!
  • Opis

  • Szczegółowe informacje

  • Recenzje (1)

Czysty kod, Podręcznik dobrego programisty - opis produktu:

Poznaj najlepsze metody tworzenia doskonałego kodu
  * Jak pisać dobry kod, a zły przekształcić w dobry?
  * Jak formatować kod, aby osiągnąć maksymalną czytelność?
  * Jak implementować pełną obsługę błędów bez zaśmiecania logiki kodu?

O tym, ile problemów sprawia niedbale napisany kod, wie każdy programista. Nie wszyscy jednak wiedzą, jak napisać ten świetny, czysty kod i czym właściwie powinien się on charakteryzować. Co więcej - jak odróżnić dobry kod od złego? Odpowiedź na te pytania oraz sposoby tworzenia czystego, czytelnego kodu znajdziesz właśnie w tej książce. Podręcznik jest obowiązkową pozycją dla każdego, kto chce poznać techniki rzetelnego i efektywnego programowania.

W książce Czysty kod. Podręcznik dobrego programisty szczegółowo omówione zostały zasady, wzorce i najlepsze praktyki pisania czystego kodu. Podręcznik zawiera także kilka analiz przypadków o coraz większej złożoności, z których każda jest doskonałym ćwiczeniem porządkowania zanieczyszczonego bądź nieudanego kodu. Z tego podręcznika dowiesz się m.in., jak tworzyć dobre nazwy, obiekty i funkcje, a także jak tworzyć testy jednostkowe i korzystać z programowania sterowanego testami. Nauczysz się przekształcać kod zawierający problemy w taki, który jest solidny i efektywny.

    * Nazwy klas i metod
    * Funkcje i listy argumentów
    * Rozdzielanie poleceń i zapytań
    * Stosowanie wyjątków
    * Komentarze
    * Formatowanie
    * Obiekty i struktury danych
    * Obsługa błędów
    * Testy jednostkowe
    * Klasy i systemy
    * Współbieżność
    * Oczyszczanie kodu

Niech stworzony przez Ciebie kod imponuje czystością!

Czysty kod, Podręcznik dobrego programisty - wybrana recenzja:

Akasza 27/03/2018
recenzja dotyczy produktu: Książki

Książka powinna być biblią dla każdego programisty. Świetnie się czyta, prawie jak dobra prozę. Praktyki opisane w książce są oderwane od konkretnej wersji Javy. Jedna z niewielu książek informatycznych, które warto kupić i się "nie przeterminują".

Czysty kod, Podręcznik dobrego programisty - szczegółowe informacje:

Dział: Książki

Kategoria: informatyka, Programowanie, Techniki programowania

Wydawnictwo: Helion
Oprawa:miękka
Okładka:miękka
Wymiary:168x237
Ilość stron:424
ISBN:978-83-283-0234-1
Wprowadzono: 18.02.2010
i zgarniaj nagrody napisz recenzję

Czysty kod, Podręcznik dobrego programisty - recenzje klientów

27/03/2018
recenzja dotyczy produktu: Książka

Książka powinna być biblią dla każdego programisty. Świetnie się czyta, prawie jak dobra prozę. Praktyki opisane w książce są oderwane od konkretnej wersji Javy. Jedna z niewielu książek informatycznych, które warto kupić i się "nie przeterminują".

10.00

Książkowe bestsellery z tych samych kategorii

Obcym alfabetem. Jak ludzie Kremla i ...

G. Rzeczkowski

książka (miękka)

25,85 zł taniej -35%

Wiedźmin Tom 1-8 Komplet

A. Sapkowski

książka (pakiet)

224,99 zł taniej -25%

Nietoperz i suszone cytryny

M. Meller

książka (miękka)

25,89 zł taniej -35%

Odbiorę ci wszystko

R. Lillegraven

książka (miękka)

25,79 zł taniej -35%

Robert C. Martin - przeczytaj też

Agile. Programowanie zwinne Zasady ...

R. Martin

M. Mic...

książka (twarda)

105,53 zł taniej -18%

Czysta architektura Struktura i design ...

R. Martin

książka (miękka)

54,80 zł taniej -18%

Mistrz czystego kodu. Kodeks ...

R. Martin

książka (miękka)

28,67 zł taniej -28%

Mistrz czystego kodu. Kodeks ...

R. Martin

książka (miękka)

26,45 zł taniej -49%

Zwinne wytwarzanie oprogramowania ...

R. Martin

książka (miękka)

81,11 zł taniej -12%

Zobacz również

CorelDRAW 2018 PL Ćwiczenia praktyczne

R. Zimek

książka (miękka)

26,11 zł taniej -25%

ABC CorelDRAW 2018 PL

R. Zimek

książka (miękka)

36,66 zł taniej -25%

Płytki drukowane (PCB) Nauka i projekty ...

S. Wallace

książka (miękka)

18,63 zł taniej -25%

Kliknij tutaj, aby zabić wszystkich ...

B. Schneier

książka (miękka)

29,85 zł taniej -25%

Ciekawe pomysły Gandalfa

książka

77.62 zł

taniej -35%

Czysty talerz Jedz zdrowiej

Pyszne jedzenie może uzdrowić ciało. Przeprowadź detoks i odzyskaj równowagę dzięki przepisom na posiłki, które szybko i łatwo przyrządzisz po całym dniu pracy. Posiłki są na tyle zdrowe, że bezpiecznie można zastosować intensywniejszą, zaaprobowaną przez lekarza kurację oczyszczającą. Gwyneth Paltrow wykorzystuje moc prostego, wysokiej jakości...

książka

47.79 zł

taniej -13%

Czysty kod w C++17 Oprogramowanie łatwe w...

Język C++ jest wszechstronnym, potężnym językiem programowania, który ma bardzo różne zastosowania. To klasyczne, wciąż udoskonalane i unowocześniane narzędzie. Problemem jednak jest to, że programiści piszący w C++ dość często mają złe nawyki. Nie przestrzegają zasad manifestu Software Craftsmanship, stosują okropną składnię, całkowicie ignorują podstawowe...

książka

27.44 zł

taniej -8%

Czysty ogień

Anka Markowska to dziewczyna, która przeżyła rodzinną tragedię. Mimo rozpaczliwej tęsknoty za najbliższymi walczy o odzyskanie życiowej równowagi. Niestety czas radości i spokoju zdaje się minąć bezpowrotnie. Za sprawą chłopaka ze snu Anka trafi w sam środek gry, w której stawką będzie jej obdarzona niebywałą mocą dusza. Dziewczyna będzie musiała wybrać...

książka

48.33 zł

taniej -12%

Software Craftsman Profesjonalizm, czysty kod i...

Coraz więcej mówi się o dobrych praktykach programistycznych, a mimo to wciąż zdarzają się przypadki wydania nieudanego produktu. Istnieje wiele przyczyn tego stanu rzeczy, np. postrzeganie procesu tworzenia oprogramowania jako linii produkcyjnej, brak właściwego zarządzania projektami, a także brak wypracowanych metod rekrutacji specjalistów i kierowania...

ebook

27.60 zł

taniej -15%

Czysty seks - mp3

Choć trudno w to uwierzyć, duża ilość małżeństw - pomimo czynnego życia seksualnego - praktycznie nigdy nie rozmawiała na ten temat między sobą! Wciąż funkcjonuje przekonanie, że przecież każdy wie, "jak to się robi" i nie ma potrzeby szczególnie dbać o "te sprawy".  Nic bardziej mylnego. Tylko szczera komunikacja, otwarcie,...

drogeria

27.27 zł

taniej -15%

Czysty Kwas Hialuronowy 1,5% trójcząsteczkowy

Czysty kwas hialuronowy skutecznie nawilża skórę oraz działa przeciwzmarszczkowo. Ujędrnia i rewitalizuje skórę. Polecany do stosowania bezpośrednio na czystą skóre, na olejek kosmetyczny lub jako dodatek do kremu.

Brak list życzeń:

Utwórz

zamówienie tradycyjne
Brak produktów w koszyku
Brak produktów w koszyku

2.99

14.99

2.99

1.98

8.99

2.35

2.84

Łączna wartość zamówienia: 0 zł0 zł
Dostawa i płatność › Płatność › przejdź do koszyka
rozwiń
Wpisz numer
Swojego zamówienia (xxxxxx/rrrr)
Sprawdź

Powiadom kiedy produkt będzie dostępny

Wpisz swój adres e-mail: