Al 09/10/2012 7:19, En/na Jordi Mas ha escrit:
Hola Jordi,
Bon dia,
Després de l'ultim e-mail he aparcat la feina que feia i aquest matí li he dedicat 15 minuts a fer una versió per la classe LogFile. A veure que us semblen les coses que hi he afegit. Se li podrien donar noves funcionalitats per a evitar de declarar-lo com a g_log i definir-lo coma a 'Singleton', però això no sé si t'interessa.
Sí, això és una cosa que caldria mirar.
He definit una nova funció WriteLog amb el mateix format del printf() per si vols simplificar el procés de generació de registres.
Les funcions segures de Microsoft (acabades en '_s') no son de la API de Windows i no són compilables amb altres compiladors. Veig que s'han utilitzat les versions definides amb template<size_t>. Si les vols eliminar i que no aparegui el warning corresponent suposo que ja saps que només caldrà definir #define _CRT_SECURE_NO_WARNINGS en el stdafx.h.
Idealment:
- Quan fas un git diff des de línia de comandes hauria d'ensenyar pocs canvis així es pot tenir una traceabilitat del que s'ha canviat. Amb el munt de canvis que hi ha és difícil entendre que s'ha canviat i perquè.
- El procés per fer canvis de refactoring hauria de ser: * Escriure una prova unitària tal com està ara * Fer els canvis * Assegurar-nos que la prova unitària funciona i no em introduir regressions.
També penso que el refactoring s'ha de fer ben fet, per això tots els canvis que estic fent els faig sobre una estructura de directoris independent, sense pujar al Github.
Per exemple, estic a punt de fer canvis significatius a l'acció de Windows 8 per afegir suport pel valencià, i el primer que he fet és afegir-hi les proves unitàries: https://github.com/Softcatala/CatalanitzadorPerAWindows/commit/fdc962c268f0b...
Que encara he d'ampliar. Així quan faci canvis, tindré més seguretat si he trencat algun funcionament previ (introduït regressions).
Coses respecte l'estil:
- Els canvis de noms de variables com ara de 'm_szFilename' a 'm_szFilename__' són inconsistents amb el sistema de noms de variables que usa el Catalanitzador.
Això era una proposta per a veure si t'agradava. Amb aquest canvi pretenia que fos més fàcil a partir del nom saber si la variable es publica, protegida o privada. ('' publica, '_' protegida i '__' privada) L'esborrem de la llista.
- Hi ha comentaris en castellà '// Creamos la linea con los parametros que nos pasan'. L'estàndard de documentació del Catalanitzador és en anglès.
Entesos
- Canviar les trucades de l'API de 'GetTempPath' a '::GetTempPath' no aporta cap valor sinó és que hi ha una coincidència amb un membre de classe, que no és el cas.
També és una forma que tinc de clarificar el codi per a saber que el que faig és cridar l'API de Windows
- Jo no introduiria els namespaces (namespace catfiles). Ho ho fem a totarreu a una classes només no té sentit.
La idea era començar per aquí i anar mica a mica.
- Al mètode _writeCompileTime has afegit la possibilitat de que funcioni amb appName == 0 ([OOOPS]) però l'únic lloc d'on es truca només es truca si 'if ( logFileName != 0 && appName != 0 )' per la qualcosa aquest camí de codi no s'executa mai.
Tens raó. És un dels molts defectes que tinc. Acostumo a escriure els procediments com a entitats independents, per a evitar que modificacions futures, fetes per mi o altres, puguin no tenir en compte aquestes coses.
- El catalanitzador segueix l'estil 'variable == valor' en comptes de 'valor==variable', com vam comentar. Per exemple, assert(0 != logFileName).
Si Jordi, he mantingut aquesta notació únicament en els assert. Ho tindré en compte. Esborrada
- Al codi es barrejen asserts de l'estil _ASSERT i assert que són diferents implementacions. Al Catalanizador usem _assert.
OK
- Canvis per suport per altres compiladors per a mi cauen dintre del que s'anomena YAGNI[2]. És a dir, canvis per un requeriment futur que no sabem si tenim. Llavors, no en faria cap si realment no és part d'un esforç complet de portar el Catalanitzador a un altre compilador, quelcom que per mi té molt baixa prioritat.
OK
- Quan fas 'if ( m_hLog__ != INVALID_HANDLE_VALUE)' i després un bloc de codi és molt habitual retornar immediatament per evitar tenir el codi identat tan a dins, és a dir, comproves la condició i retornes, i el condi continua després sense necessitat d'estar a un bloc.
Això bé d'una de les normes del software de seguretat. Diuen que cal intentar tenir únicament un punt de retorn, per això intento sempre no tenir returns entre el codi.
Al final, m'agradaria que els canvis que fossin necessaris.
Jordi, et proposo:
1) Quedem un dia després de la feina, i fem aquests canvis conjuntament perquè penso que per correu electrònic això es farà etern.
2) Creem una guia d'estil que reflexi quin l'estil de codificació actual, i quines coses cal canviar.
3) Documentem i prioritzem tots els refactorings que cal fer. Tinc una llista llarga també.
Com ho veus?
A mi em sembla indispensable això de quedar perquè els dos estils de programació són molt diferents i jo no sé per on començar a ajudar. Veig que moltes de les coses que a faig, necessàries per la meva feina, no ho són per aquest projecte. Salutacions Jordi Latorre [1] https://github.com/Softcatala/CatalanitzadorPerAWindows/blob/master/Catalani...