Istnieją standardy kodowania, które zwiększają produktywność zespołów. Teoretycznie ułatwiają zrozumienie, modyfikację i testowanie kodu. W praktyce mogą stworzyć niebezpieczną ilość meta-pracy; zespoły wielokrotnie przepisują istniejący kod w poszukiwaniu najbardziej poprawnego i eleganckiego rozwiązania. Niestety problem meta-pracy wydaje się gorszy w zespołach, w których wszyscy są zaangażowani, pasjonaci i mają obsesję na punkcie robienia właściwych rzeczy.
Jako konsultant przechodzący od projektu do projektu odkryłem, że doskonała dyscyplina ze sztywnym standardem kodowania przyczynia się znacznie mniej do sukcesu projektu niż doskonali programiści, którzy są zainteresowani wynikami. Niespójne style kodowania są drobną uciążliwością dla niesamowitych programistów. Są wydajne z konsekwencją lub bez niej. To prawda, że jeśli napotkają niespójny kod, zapytają o bieżącystandard i trzymaj się go. Nie będą jednak nalegać na aktualizację każdej linii kodu w projekcie do obecnego standardu. Nie nalegają, ponieważ widzieli, jak najlepsze praktyki przychodzą i odchodzą. Właściwy sposób robienia czegoś dzisiaj nie jest taki sam, jak właściwy sposób robienia czegoś jutro. Gdyby tak było, standardy kodowania nie ewoluowałyby. Tak więc, jeśli poprawny sposób zrobienia czegoś zmienia się z czasem, być może nasza definicja „poprawności” jest zepsuta.
Nie oznacza to, że standardy nie mają znaczenia. Pamiętaj tylko, że celem norm jest produktywność. Jeśli nie możesz zagwarantować, że ponowne napisanie do nowego standardu zwróci się w dłuższej perspektywie, nie marnuj na to czasu. O wiele łatwiej jest uzasadnić nowy standard w nowym lub zmienionym kodzie. Elegancja jest fajna, ale to nie to samo, co wyniki.
Osobiście wolałbym zachować stare kody w obecnej postaci i stosować się do nowych standardów, niezależnie od tego, co robisz. Mówiąc dokładniej, nie będę używał podwójnych standardów w old.c. Ale jeśli mam utworzyć new.c, można użyć nowszych, dopracowanych składni :)
źródło