Tiszta kód hibajegyzék

A Tiszta kód című könyvben (Robert C. Martin, 2010, ISBN: 9789639637696) általam felfedezett hibák listája alább.

1. fejezet, Tiszta kód

  • 8. oldal: 404-es link a lap alján.

2. fejezet, Beszédes nevek

  • 20. oldal: A középső forráskód minden sorának végéről lemaradt a pontosvessző, a szokásos java-konvenciókkal ellentétesen egyes változónevek nem kisbetűvel kezdődnek. Valamint teljesen felesleges volt lefordítani őket.
  • 29. oldal: „string” helyett „String” a helyes. (Eredetiben is hibás.)

5. fejezet, Formázás

  • 99. oldal: A 15.5-ös és 3.7-es példára történő hivatkozásnál kimaradt az oldalszám. (Eredetiben szerepel.)

6. fejezet, Objektumok és adatszerkezetek

  • 117. oldal: „address.java” helyett „Address.java”. (Az eredetiben is hibás.)

7. fejezet, Hibakezelés

  • 127. oldal: A Fowler hivatkozás lemaradt a fejezet végéről (az eredetiben is).

8. fejezet, Határok

  • 138. oldal: Az ábráról lemarad a Fake Transmitter és a Transmitter Adapter felirat.
  • 139. oldal: Első bekezdés, „működésének” helyett „működés”.

11. fejezet, Rendszerek

  • 183. oldal: Az ötödik bekezdés eléggé szerencsétlenül van fordítva.
  • 177. oldal: Lábjegyzet, „Mezzaros” helyett „Meszaros” (Eredetiben is rossz). Ugyanígy a fejezet végén is rossz a hivatkozás.
  • 191. oldal: Negyedik bekezdést angolul ezerszer könnyebb megérteni. Az „integrate” kölcsönhatásnak van fordítva...

13. fejezet, Párhuzamosság

  • 215. oldal: A „several configurations” „többféle felépítés”-nek lett fordítva.

14. fejezet, Fokozatos finomítás

  • 238. oldal: „integer” – nagybetűvel lenne helyes, eredetiben is rossz. 242. oldalon szintén. Mindenesetre dicséretes, hogy nem fordították le.
  • 246. oldal: A „private String stringValue” kiemelése hiányzik. (Eredetiben szerepel.)
  • „ArgumentMarshaller” név a szövegben két l, kódban egy. 248. oldalon szintén.
  • 256. oldal: Az áthúzások vonala túl vastag, nehezen olvasható a mögöttük lévő szöveg. (Eredetiben jobb.)

17. fejezet, Szagok és szabályok

  • 345. oldal: Rejtett ideiglenes csatolások: A „temporal” nem ideiglenes, hanem időbeli! Fontos különbség. Nem ideiglenes a csatolás, hanem a sorrendjük, a végrehajtás ideje okozza a csatolást.

Továbbá fejezettől függetlenül (talán) az összes forráskód át lett tördelve. A szép kódok csúnyák lettek, a csúnyának szántak pedig még rondábbak. Pedig ebben a könyvben pont a szép kódokon van (illetve lenne) a hangsúly.

Hozzászólások

Emergence magyarul

12. fejezet - Láthatóság = Emergence

195. oldal - a wikipédia megjelenésre fordítja a szót, magyar irodalmi hivatkozás nincs

Forrás: http://hu.wikipedia.org/wiki/Megjelen%C3%A9s

Konkrétabban itt van szó emergens tervezésről:

http://xprogramming.com/classics/expemergentdesign/

A megjelenés mint tudomány azt állítja, hogy magas szintű rend és szervezettség az egyszerű szabályokat követő egyedek (mint egy hangyaboly hangyái, egy élő szervezet sejtjei, egy árvíz vízcseppjei, vagy egy hegyomlás kövei) alacsony szintű kölcsönhatásainak megnyilvánulásai.

A láthatóság használata itt teljesen rossz és félrevezető, ráadásul ez fejezetcím(!).

Amit itt ki kellene fejezni, hogy a rendszer szabályaiból fakadó, "nem várt rend felbukkanása".

Ezt próbálja kifejezni a fejezet elején lévő színpompás pillangó, ami a viszonylag egyszerű megjelenésű hernyóból alakul ki.

+++

8. oldal:
http://www.pragprog.com/the-pragmatic-programmer/extracts/software-entropy

99. oldal:
15.5. példa -> 301. oldal, 3.7. példa -> 59. oldal

127. oldal:
http://martinfowler.com/eaaCatalog/specialCase.html

183. oldal:

In principle, you can reason about your persistence strategy in a modular, encapsulated way. Yet, in practice, you have to spread essentially the same code that implements the persistence strategy across many objects. We use the term cross-cutting concerns for concerns like these. Again, the persistence framework might be modular and our domain logic, in isolation, might be modular. The problem is the fine-grained intersection of these domains.

191. oldal:

An optimal system architecture consists of modularized domains of concern, each of which is implemented with Plain Old Java (or other) Objects. The different domains are integrated together with minimally invasive Aspects or Aspect-like tools. This architecture can be test-driven, just like the code.

Könyvben fordított:
Az optimális rendszerszerkezet moduláris feladattartományokból épül fel, amelyeket POJO-kkal vagy más objektumokkal valósítunk meg. A különböző tartományok közötti kölcsönhatásokat a kódba a lehető legkisebb mértékben beavatkozó aspektusok, illetve hozzájuk hasonló eszközök biztosítják. Ezt a rendszert már hatékonyan tesztelhetjük, hasonlóan a kódhoz.

345. oldal:
Lehetett volna még Rejtett halánték csatolások :)

Tartalom átvétel