[Desenvolupament] Llibreria libcatz
Jordi Latorre
jlatorref a terra.es
dim oct 9 09:37:20 CEST 2012
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/fdc962c268f0b1966eb7dd8811cbc805ce4e5233
>
>
> 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/CatalanitzadorPerAWindows/Core/Configuration/ConfigurationInstance.h
> [2] http://en.wikipedia.org/wiki/You_ain%27t_gonna_need_it
Més informació sobre la llista de correu Desenvolupament