Bon en général je ne fais pas ça mais c'est trop incroyable. Je dois me taper le refacto d'une classe écrite par une trèèèès grosse boite de service pour mon client et qui calcule des dates spéciales en Java, dans le cas que je corrige, il s'agit de Pâques...
Je ne vous mets qu'un extrait du code (le reste est tout aussi incroyable mais je ne veux pas de problème de copyreich) :
private static GregorianCalendar calculJourPaques(int pYear) {
GregorianCalendar vPaques = new GregorianCalendar();
int vA = pYear % 19;
int vB = pYear / 100;
int vC = pYear % 100;
int vD = vB / 4;
int vE = vB % 4;
int vF = (vB + 8) / 25;
int vG = (vB - vF + 1) / 3;
int vH = (19 * vA + vB - vD - vG + 15) % 30;
int vI = vC / 4;
int vK = vC % 4;
int vL = (32 + 2 * vE + 2 * vI - vH - vK) % 7;
int vM = (vA + 11 * vH + 22 * vL) / 451;
int vN = (vH + vL - 7 * vM + 114) / 31;
int vP = (vH + vL - 7 * vM + 114) % 31;
vPaques.set(pYear, vN - 1, vP + 1);
vPaques.add(5, 1);
return vPaques;
}
Alors oui, le code est en français, oui les variables sont préfixées par un "p" pour dire qu'elles sont paramètres de la méthode et par un "v" pour indiquer qu'elles sont de simples variables dans cette méthode...
Sinon c'est un "a" (pour attribut) ou "f" (pour field) mais un attribut c'est aussi parfois un "c"... Bah oui vous comprenez, certains développeurs avaient de gros doigts donc ils ont appuyé à côté du "f" sur la touche "c"... Et d'autres ont simplement reproduit cette erreur pour que le préfix "c" corresponde aux attributs. #Enjoy
J'ai déjà patché du code compliqué, du code de merde, du code inutile, du code ultra-théorique à base de formules complexes mais je n'avais jamais dû patcher du code dont je ne peux décrire l'origine !
P.S : vous remarquerez que l'algorithme est juste une prouesse de complexité hein (T_T). J'ai déjà pu identifier que l'on parlait d'année bissextile et heureusement ! Vive les TU (que je vais devoir créer parce que trop marrant sinon).
Edit : l’algorithme est celui de Butcher-Meeus.
Un set de best-pratices de Stack Overflow.
Martin Fowler toujours aussi efficace dans ses explications.
Une vision plus théorique des techniques de refactoring mais toujours bon à avoir.
Je commence une suite de postes sur les techniques de refactoring de code (legacy) ou d'autres techniques de nettoyage de code.