[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