[Desenvolupament] Llibreria libcatz
Bon tarda a tots, Com que el projecte Catalanitzador ha crescut molt, i per a posar-me a treballar m'agradaria coneixer bé el codi d'en Jordi Mas he començat a preparar una llibreria 'libcatz' amb les classes originals convenientment modificades en les seves entranyes de manera que el codi sigui el màxim portable. A més, també he pogut veure que ha crescut molt ràpid i no se li ha pogut dedicar molt temps a protegir el codi contra possibles errors del programador. Així que proposo: - Utilitzar els namespaces per a contenir al màxim el codi i no equivocar-nos. - Utilitzar més herències per a reduir el tamany dels fitxers. - Protegir més les variables dins de les classes. Jordi, comprenc que a tot programador li 'fot' molt que toquin el propi codi. Què et sembla si t'envio una petita mostra? Salutacions Jordi Latorre
Bona tarda,
Com que el projecte Catalanitzador ha crescut molt, i per a posar-me a treballar m'agradaria coneixer bé el codi d'en Jordi Mas he començat a preparar una llibreria 'libcatz' amb les classes originals convenientment modificades en les seves entranyes de manera que el codi sigui el màxim portable. A més, també he pogut veure que ha crescut molt
Quan et refereixes al màxim portable pots posar alguns exemples?
ràpid i no se li ha pogut dedicar molt temps a protegir el codi contra possibles errors del programador. Així que proposo:
- Utilitzar els namespaces per a contenir al màxim el codi i no equivocar-nos.
El tema dels namespaces em sembla bé. La confusió potencial que soluciona és bàsicament utilitzar una classe per altre.
- Utilitzar més herències per a reduir el tamany dels fitxers.
Tens alguns exemples de fitxers que voldries reduir amb herències?
- Protegir més les variables dins de les classes.
Pots posar alguns exemples?
Jordi, comprenc que a tot programador li 'fot' molt que toquin el propi codi. Què et sembla si t'envio una petita mostra?
No tinc vincles emocionals amb el codi. Qualsevol canvi em sembla bé que sigui una millora. Atentament, Jordi, [1] http://en.wikipedia.org/wiki/You_ain't_gonna_need_it -- Jordi Mas i Hernàndez -Bloc: http://gent.softcatala.org/jmas/bloc/ Planet Softcatalà -> http://planeta.softcatala.org
Bon dia, Al 04/10/2012 20:31, En/na Jordi Mas ha escrit:
Bona tarda,
Com que el projecte Catalanitzador ha crescut molt, i per a posar-me a treballar m'agradaria coneixer bé el codi d'en Jordi Mas he començat a preparar una llibreria 'libcatz' amb les classes originals convenientment modificades en les seves entranyes de manera que el codi sigui el màxim portable. A més, també he pogut veure que ha crescut molt
Quan et refereixes al màxim portable pots posar alguns exemples?
Això és deformació professional. Intentar que el codi s'ajusti al màxim a les llibreries ANSI C, ANSI C++, STL etc.. per si algun dia volem que pugui compilar amb qualsevol compilador. Així, en el cas del fitxer de log proposo utilitzar _wfopen enlloc de CreateFile, fclose enlloc de CloseHandle, etc... En el cas de les dates enlloc d'utilitzar el GetLocalTime proposo utilitzar _ftime64 i _localtime64. Tots aquests canvis els he implementat i la generació del fitxer queda exactament com en el cas del Catalanitzador actual.
ràpid i no se li ha pogut dedicar molt temps a protegir el codi contra possibles errors del programador. Així que proposo:
- Utilitzar els namespaces per a contenir al màxim el codi i no equivocar-nos.
El tema dels namespaces em sembla bé. La confusió potencial que soluciona és bàsicament utilitzar una classe per altre. Una altra cosa que he vist en el codi és la utilització del '/using/'.
using namespace std; A mi particularment no m'agrada donat que es perden les avantatges dels namespaces. Prefereixo escriure més, però tenir més control del que toco. Si cal escriure "std::cout << std::endl" el codi queda una mica més comprensible i evitem errors.
- Utilitzar més herències per a reduir el tamany dels fitxers.
Tens alguns exemples de fitxers que voldries reduir amb herències?
- Protegir més les variables dins de les classes.
Pots posar alguns exemples? En el cas de 'HANDLE m_hLog' es pot escriure en ell des de diversos
En treballar amb el fitxer LogFile, i per evitar tocar l'interface que utilitzes he fet el següent: files::LogFile -> files::filebase files::ffile : accés al fitxer de log En la classe filebase tinc un punter a un fitxer ffile que és el que realment accedeix al fitxer. ffile acaba estant com a private de filebase, de manera que queda protegit i al mateix temps el FILE* dins de ffile també és private protegint el seu valor i l'accés. La classe filebase únicament té sentit per a protegir la interface que estàs utilitzant. He tret algunes rutines protegides de Logfile per a posar-les dins de filebase. punts dins de la classe mateixa i en cap d'ells es comprova si el valor de la variable té un valor bo. De fet et disparará una excepció l'aplicació si no crides CreateLog un cop has creat l'objecte. Ja t'he comentat que estic molt pervertit pel meu món de programació, i potser no fa falta controlar tant el codi, encara que crec que pot ajudar.
Jordi, comprenc que a tot programador li 'fot' molt que toquin el propi codi. Què et sembla si t'envio una petita mostra?
No tinc vincles emocionals amb el codi. Qualsevol canvi em sembla bé que sigui una millora.
Caldria que les classes i el codi mantinguéssin un mateix Coding Standard. - Una de les coses que m'agrada és el '_' que afegeixes davant de les rutines protegides i que utilitzaré a partir d'ara en els meus desenvolupaments futurs. - He vist també que en alguns casos utilitzes 'm_' davant de variables de classe i en d'altres no. A mi m'agrada afegir '_' al final de la variable per a protegides i '__' (2 _) per a les privades. - Respecte als if (...) una cosa que podries fer i que el MISRA C recomana és posar el valor de la constant abans per a que el compilador t'avisi si t'equivoques: (0 != variable) enlloc de (variable != 0). Això evitaria errors difícils de trobar com if(variable = 0) // == - A l'entrada de rutines caldria afegir comprovacions de validesa i de rang utilitzant 'asserts' per a que al "debugar" cantin els errors. - Utilitzar el modificador 'const' per a variables d'entrada i no sortida. - A la classe LogFile he afegit una rutina writeLog(const wchar_t* format, ...) similar al printf per a evitar la sobrecàrrega de Log(wchar_t*), Log(wchar_t*,wchar_t*), etc...
Atentament,
Jordi,
La referència està força bé. Espero que les propostes t'agradin, no sóc ningú per a fer res sense el teu consentiment. Això em pot donar molta feina i crec que pot ajudar al manteniment i clarificació de tot el codi. Atentament, Jordi L.
Hola Jordi,
Això és deformació professional. Intentar que el codi s'ajusti al màxim a les llibreries ANSI C, ANSI C++, STL etc.. per si algun dia volem que pugui compilar amb qualsevol compilador.
Així, en el cas del fitxer de log proposo utilitzar _wfopen enlloc de CreateFile, fclose enlloc de CloseHandle, etc...
En el cas de les dates enlloc d'utilitzar el GetLocalTime proposo utilitzar _ftime64 i _localtime64.
Tots aquests canvis els he implementat i la generació del fitxer queda exactament com en el cas del Catalanitzador actual.
Qualsevol compilador al que en el futur migrem haurà de tenir suport pel Windows API ja que el Catalanitzador és una aplicació Windows que usa el seu API extensivament[1]. Per exemple el gcc per a Windows, Borland o qualsevol altre ofereixen suport a l'API de Windows. Llavors, aquests canvis no ens donen cap flexibilitat real. Una cosa diferent seria que estiguessis fent el porting per poder compilar amb gcc i que calgues fer aquests canvis per poder-ho fer, però no és el cas i tampoc són necessaris.
using namespace std;
A mi particularment no m'agrada donat que es perden les avantatges dels namespaces. Prefereixo escriure més, però tenir més control del que toco. Si cal escriure "std::cout << std::endl" el codi queda una mica més comprensible i evitem errors.
És una qüestió d'estil. Per exemple, l'estil del Catalanitzador és com funciona Java o C# per exemple: declares els namespaces que vols usar i després pots fer referencies a ells de forma més curta i sintètica.
En treballar amb el fitxer LogFile, i per evitar tocar l'interface que utilitzes he fet el següent:
files::LogFile -> files::filebase files::ffile : accés al fitxer de log
En la classe filebase tinc un punter a un fitxer ffile que és el que realment accedeix al fitxer. ffile acaba estant com a private de filebase, de manera que queda protegit i al mateix temps el FILE* dins de ffile també és private protegint el seu valor i l'accés. La classe filebase únicament té sentit per a protegir la interface que estàs utilitzant. He tret algunes rutines protegides de Logfile per a posar-les dins de filebase.
En la meva opinió, el principal problema de LogFile és més greu. Es veu de seguida: g_log.Log(L"MSOfficeLPIAction::_setDefaultLanguage, set FollowSystemUI %u", (wchar_t *) bSetFollowKey); El fet que no funcioni com un pipe i que calgui fer tots aquests castings. Canviar això realment té risc, ho vaig provar.
En el cas de 'HANDLE m_hLog' es pot escriure en ell des de diversos punts dins de la classe mateixa i en cap d'ells es comprova si el valor de la variable té un valor bo. De fet et disparará una excepció l'aplicació si no crides CreateLog un cop has creat l'objecte. Ja t'he comentat que estic molt pervertit pel meu món de programació, i potser no fa falta controlar tant el codi, encara que crec que pot ajudar.
Caldria que les classes i el codi mantinguéssin un mateix Coding Standard.
- Una de les coses que m'agrada és el '_' que afegeixes davant de les rutines protegides i que utilitzaré a partir d'ara en els meus desenvolupaments futurs.
Això ve de la necessitat d'haver de tenir mètodes amb signatura 'protected' per tal de poder fer proves unitàries. Llavors, per això faig servir aquesta nomenclatura.
- He vist també que en alguns casos utilitzes 'm_' davant de variables de classe i en d'altres no. A mi m'agrada afegir '_' al final de la variable per a protegides i '__' (2 _) per a les privades.
És qüestió de conveccions, al final s'ha d'escollir una o un altre i cap és millor que altre.
- Respecte als if (...) una cosa que podries fer i que el MISRA C recomana és posar el valor de la constant abans per a que el compilador t'avisi si t'equivoques: (0 != variable) enlloc de (variable != 0). Això evitaria errors difícils de trobar com if(variable = 0) // ==
He vist aquesta practica, en general hi ha molts pocs programes lliures que la segueixin.
- A l'entrada de rutines caldria afegir comprovacions de validesa i de rang utilitzant 'asserts' per a que al "debugar" cantin els errors.
He afegit alguns allà on aporten valor immediat, com la màquina d'estats de les accions[1]. Els asserts són una bona cosa.
- Utilitzar el modificador 'const' per a variables d'entrada i no sortida.
Els const certament no s'usa tot arreu on es podria usar. Ho trobo una molt bona cosa.
- A la classe LogFile he afegit una rutina writeLog(const wchar_t* format, ...) similar al printf per a evitar la sobrecàrrega de Log(wchar_t*), Log(wchar_t*,wchar_t*), etc... La referència està força bé.
Espero que les propostes t'agradin, no sóc ningú per a fer res sense el teu consentiment. Això em pot donar molta feina i crec que pot ajudar al manteniment i clarificació de tot el codi.
El problema que hi ha amb els canvis és que molts d'aquests canvis tenen molt poc valor funcional (impacte per l'usuari) o no redueixen significament el cost de manteniment, i poden tenir un impacte en introduir noves errades. Veure el pla de proves per fer-se una idea[2] del que cal provar cada vegada que fem canvis significatius. Si em preguntessis que penso que cal prioritzar seria: 1) Ampliar la cobertura de proves unitàries que ens ajudin a reduir les proves que hem de fer i la feina amb el procés de proves[2]. Això ens permetrà: - Alliberar versions més sovint amb menys esforç - Fer refactorings en el futur amb menys risc 2) Ampliar la funcionalitat. Hi ha una llista d'errors i coses a fer molt important [3]. Algunes petites però interessants i importants. La podem prioritzar. 3) Fer 'refactorings' de baix risc que facilitin el manteniment. Dels canvis que proposes jo els hi veig més valor a: introduir const, asserts i els canvis que introdueixen consistència amb el que hi ha fet (per exemple, noms de variables). Atentament, Jordi, [1] https://github.com/Softcatala/CatalanitzadorPerAWindows/blob/master/Catalani... [2] http://www.softcatala.org/wiki/Projectes/Catalanitzador_Per_Al_Windows/Pla_d... [3] http://www.softcatala.org/wiki/Projectes/Catalanitzador_per_al_Windows/Coses... -- Jordi Mas i Hernàndez -Bloc: http://gent.softcatala.org/jmas/bloc/ Planet Softcatalà -> http://planeta.softcatala.org
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. 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. Salutacions Jordi Latorre Al 05/10/2012 9:20, En/na Jordi Latorre ha escrit:
Bon dia,
Al 04/10/2012 20:31, En/na Jordi Mas ha escrit:
Bona tarda,
Com que el projecte Catalanitzador ha crescut molt, i per a posar-me a treballar m'agradaria coneixer bé el codi d'en Jordi Mas he començat a preparar una llibreria 'libcatz' amb les classes originals convenientment modificades en les seves entranyes de manera que el codi sigui el màxim portable. A més, també he pogut veure que ha crescut molt
Quan et refereixes al màxim portable pots posar alguns exemples?
Això és deformació professional. Intentar que el codi s'ajusti al màxim a les llibreries ANSI C, ANSI C++, STL etc.. per si algun dia volem que pugui compilar amb qualsevol compilador.
Així, en el cas del fitxer de log proposo utilitzar _wfopen enlloc de CreateFile, fclose enlloc de CloseHandle, etc...
En el cas de les dates enlloc d'utilitzar el GetLocalTime proposo utilitzar _ftime64 i _localtime64.
Tots aquests canvis els he implementat i la generació del fitxer queda exactament com en el cas del Catalanitzador actual.
ràpid i no se li ha pogut dedicar molt temps a protegir el codi contra possibles errors del programador. Així que proposo:
- Utilitzar els namespaces per a contenir al màxim el codi i no equivocar-nos.
El tema dels namespaces em sembla bé. La confusió potencial que soluciona és bàsicament utilitzar una classe per altre. Una altra cosa que he vist en el codi és la utilització del '/using/'.
using namespace std;
A mi particularment no m'agrada donat que es perden les avantatges dels namespaces. Prefereixo escriure més, però tenir més control del que toco. Si cal escriure "std::cout << std::endl" el codi queda una mica més comprensible i evitem errors.
- Utilitzar més herències per a reduir el tamany dels fitxers.
Tens alguns exemples de fitxers que voldries reduir amb herències?
En treballar amb el fitxer LogFile, i per evitar tocar l'interface que utilitzes he fet el següent:
files::LogFile -> files::filebase files::ffile : accés al fitxer de log
- Protegir més les variables dins de les classes.
Pots posar alguns exemples? En el cas de 'HANDLE m_hLog' es pot escriure en ell des de diversos
En la classe filebase tinc un punter a un fitxer ffile que és el que realment accedeix al fitxer. ffile acaba estant com a private de filebase, de manera que queda protegit i al mateix temps el FILE* dins de ffile també és private protegint el seu valor i l'accés. La classe filebase únicament té sentit per a protegir la interface que estàs utilitzant. He tret algunes rutines protegides de Logfile per a posar-les dins de filebase. punts dins de la classe mateixa i en cap d'ells es comprova si el valor de la variable té un valor bo. De fet et disparará una excepció l'aplicació si no crides CreateLog un cop has creat l'objecte. Ja t'he comentat que estic molt pervertit pel meu món de programació, i potser no fa falta controlar tant el codi, encara que crec que pot ajudar.
Jordi, comprenc que a tot programador li 'fot' molt que toquin el propi codi. Què et sembla si t'envio una petita mostra?
No tinc vincles emocionals amb el codi. Qualsevol canvi em sembla bé que sigui una millora.
Caldria que les classes i el codi mantinguéssin un mateix Coding Standard.
- Una de les coses que m'agrada és el '_' que afegeixes davant de les rutines protegides i que utilitzaré a partir d'ara en els meus desenvolupaments futurs.
- He vist també que en alguns casos utilitzes 'm_' davant de variables de classe i en d'altres no. A mi m'agrada afegir '_' al final de la variable per a protegides i '__' (2 _) per a les privades.
- Respecte als if (...) una cosa que podries fer i que el MISRA C recomana és posar el valor de la constant abans per a que el compilador t'avisi si t'equivoques: (0 != variable) enlloc de (variable != 0). Això evitaria errors difícils de trobar com if(variable = 0) // ==
- A l'entrada de rutines caldria afegir comprovacions de validesa i de rang utilitzant 'asserts' per a que al "debugar" cantin els errors.
- Utilitzar el modificador 'const' per a variables d'entrada i no sortida.
- A la classe LogFile he afegit una rutina writeLog(const wchar_t* format, ...) similar al printf per a evitar la sobrecàrrega de Log(wchar_t*), Log(wchar_t*,wchar_t*), etc...
Atentament,
Jordi,
La referència està força bé.
Espero que les propostes t'agradin, no sóc ningú per a fer res sense el teu consentiment. Això em pot donar molta feina i crec que pot ajudar al manteniment i clarificació de tot el codi.
Atentament,
Jordi L.
_______________________________________________ Desenvolupament mailing list Desenvolupament@llistes.softcatala.org http://llistes.softcatala.org/mailman/listinfo/desenvolupament _______________________________________________ Codi de conducta: http://www.softcatala.org/wiki/Codi_de_conducta
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. 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. - 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. - 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. - Jo no introduiria els namespaces (namespace catfiles). Ho ho fem a totarreu a una classes només no té sentit. - 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. - El catalanitzador segueix l'estil 'variable == valor' en comptes de 'valor==variable', com vam comentar. Per exemple, assert(0 != logFileName). - Al codi es barrejen asserts de l'estil _ASSERT i assert que són diferents implementacions. Al Catalanizador usem _assert. - 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. - 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. 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? Atentament, Jordi, [1] https://github.com/Softcatala/CatalanitzadorPerAWindows/blob/master/Catalani... [2] http://en.wikipedia.org/wiki/You_ain%27t_gonna_need_it -- Jordi Mas i Hernàndez -Bloc: http://gent.softcatala.org/jmas/bloc/ Planet Softcatalà -> http://planeta.softcatala.org
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...
participants (2)
-
Jordi Latorre -
Jordi Mas