Bei der Gruppe, für die Sie eine Mitteilung verfassen, handelt es sich um eine Usenet-Gruppe. Wenn Sie in dieser Gruppe Nachrichten posten, ist Ihre E-Mail-Adresse für jeden im Internet sichtbar
Zusätzlich habe ich ein paar Rails-spezifische Checks eingebaut:
* AttrAccessibleCheck (checkt dass attr_accessible verwendet wird)
* AttrProtectedCheck (checkt dass attr_protected nicht verwendet wird,
besser Whitelist per attr_accessible)
* InstanceVarInPartialCheck (checkt dass in Partials keine
Instanzvariablen verwendet werden, die das Partial abhängig vom
Controller oder der View machen)
* ValidationsCheck (checkt dass Models Validations definieren)
Insbesondere bei den Rails spezifischen Checks sehe ich Potential, da
mit solchen Checks ganz konkrete Probleme und Fehlerquellen erkannt
werden können. Die allgemeinen Checks zur Komplexität usw. sind ja
immer nur mögliche Fehlerquellen, Instanzvariablen in Partials aber
bspw. ganz konkrete Code Smells.
Was haltet Ihr davon? Ist das nützlich/ würdet Ihr das verwenden
(insb. auch in Kombination mit CI)? Wem fallen noch weitere Checks
ein, die man implementieren könnte?
Auf unserem nächsten Treffen stelle ich das gerne auch mal im Detail
vor, zusammen mit reports_as_sparkline.
> Zusätzlich habe ich ein paar Rails-spezifische Checks eingebaut:
> * AttrAccessibleCheck (checkt dass attr_accessible verwendet wird)
> * AttrProtectedCheck (checkt dass attr_protected nicht verwendet wird,
> besser Whitelist per attr_accessible)
> * InstanceVarInPartialCheck (checkt dass in Partials keine
> Instanzvariablen verwendet werden, die das Partial abhängig vom
> Controller oder der View machen)
> * ValidationsCheck (checkt dass Models Validations definieren)
> Insbesondere bei den Rails spezifischen Checks sehe ich Potential, da
> mit solchen Checks ganz konkrete Probleme und Fehlerquellen erkannt
> werden können. Die allgemeinen Checks zur Komplexität usw. sind ja
> immer nur mögliche Fehlerquellen, Instanzvariablen in Partials aber
> bspw. ganz konkrete Code Smells.
> Was haltet Ihr davon? Ist das nützlich/ würdet Ihr das verwenden
> (insb. auch in Kombination mit CI)? Wem fallen noch weitere Checks
> ein, die man implementieren könnte?
> Auf unserem nächsten Treffen stelle ich das gerne auch mal im Detail
> vor, zusammen mit reports_as_sparkline.
>> Excellent macht Source Code Analyse auf Ruby Code und wendet dabei
>> ein
>> paar Checks an, die u.A. von roodi, reek und flog übernommen sind,
>> bspw:
>> Zusätzlich habe ich ein paar Rails-spezifische Checks eingebaut:
>> * AttrAccessibleCheck (checkt dass attr_accessible verwendet wird)
>> * AttrProtectedCheck (checkt dass attr_protected nicht verwendet
>> wird,
>> besser Whitelist per attr_accessible)
>> * InstanceVarInPartialCheck (checkt dass in Partials keine
>> Instanzvariablen verwendet werden, die das Partial abhängig vom
>> Controller oder der View machen)
>> * ValidationsCheck (checkt dass Models Validations definieren)
>> Insbesondere bei den Rails spezifischen Checks sehe ich Potential, da
>> mit solchen Checks ganz konkrete Probleme und Fehlerquellen erkannt
>> werden können. Die allgemeinen Checks zur Komplexität usw. sind ja
>> immer nur mögliche Fehlerquellen, Instanzvariablen in Partials aber
>> bspw. ganz konkrete Code Smells.
>> Was haltet Ihr davon? Ist das nützlich/ würdet Ihr das verwenden
>> (insb. auch in Kombination mit CI)? Wem fallen noch weitere Checks
>> ein, die man implementieren könnte?
>> Auf unserem nächsten Treffen stelle ich das gerne auch mal im Detail
>> vor, zusammen mit reports_as_sparkline.
Ist eigentlich find_by_sql nun guter/schlechter Stil?
Aber ich würde dazu auf jeden Fall mal gerne Werte sehen. (Portierbarkeit auf andere DB, Probleme bei Tabellenumbenennungen oder anderen Migrationen... weiss aber nicht ob das grundsätzlich etwas über die Codequali aussagt - evtl. nur Performancetuning).
>>> Excellent macht Source Code Analyse auf Ruby Code und wendet dabei
>>> ein
>>> paar Checks an, die u.A. von roodi, reek und flog übernommen sind,
>>> bspw:
>>> Zusätzlich habe ich ein paar Rails-spezifische Checks eingebaut:
>>> * AttrAccessibleCheck (checkt dass attr_accessible verwendet wird)
>>> * AttrProtectedCheck (checkt dass attr_protected nicht verwendet
>>> wird,
>>> besser Whitelist per attr_accessible)
>>> * InstanceVarInPartialCheck (checkt dass in Partials keine
>>> Instanzvariablen verwendet werden, die das Partial abhängig vom
>>> Controller oder der View machen)
>>> * ValidationsCheck (checkt dass Models Validations definieren)
>>> Insbesondere bei den Rails spezifischen Checks sehe ich Potential, da
>>> mit solchen Checks ganz konkrete Probleme und Fehlerquellen erkannt
>>> werden können. Die allgemeinen Checks zur Komplexität usw. sind ja
>>> immer nur mögliche Fehlerquellen, Instanzvariablen in Partials aber
>>> bspw. ganz konkrete Code Smells.
>>> Was haltet Ihr davon? Ist das nützlich/ würdet Ihr das verwenden
>>> (insb. auch in Kombination mit CI)? Wem fallen noch weitere Checks
>>> ein, die man implementieren könnte?
>>> Auf unserem nächsten Treffen stelle ich das gerne auch mal im Detail
>>> vor, zusammen mit reports_as_sparkline.
...wie ich mir genau das gleiche gedacht habe... =)
Klingt aber gut um unsere Trainees und neue Kollegen zu quälen.
Mir fallen momentan nur Konventions ein die ich mir gesetzt habe...
-geschachtelte Verzweigungen wo man eigentlich switchen könnte
-reserved words, terms, helper etc. (weiß nicht wie oft mir deswegen schon n Controller unserer externen um die Ohren geflogen ist)
-richtige pluralisierung (scheint doch für einige n problem zu sein)
-richtige und minimal nötige Routen
-@muh = params[:bla] im view:
= @muh
-h() und sanitize, wenigstens wenn obiges
-proper "css'ing"
Ist jetzt mal ausm Kopf so das häufigste was mir auffiel.
Mir fällt noch ne Menge HAML spezifisches ein, ka ob du da überhaupt hin möchtest.
>> Excellent macht Source Code Analyse auf Ruby Code und wendet dabei ein
>> paar Checks an, die u.A. von roodi, reek und flog übernommen sind,
>> bspw:
>> Zusätzlich habe ich ein paar Rails-spezifische Checks eingebaut:
>> * AttrAccessibleCheck (checkt dass attr_accessible verwendet wird)
>> * AttrProtectedCheck (checkt dass attr_protected nicht verwendet wird,
>> besser Whitelist per attr_accessible)
>> * InstanceVarInPartialCheck (checkt dass in Partials keine
>> Instanzvariablen verwendet werden, die das Partial abhängig vom
>> Controller oder der View machen)
>> * ValidationsCheck (checkt dass Models Validations definieren)
>> Insbesondere bei den Rails spezifischen Checks sehe ich Potential, da
>> mit solchen Checks ganz konkrete Probleme und Fehlerquellen erkannt
>> werden können. Die allgemeinen Checks zur Komplexität usw. sind ja
>> immer nur mögliche Fehlerquellen, Instanzvariablen in Partials aber
>> bspw. ganz konkrete Code Smells.
>> Was haltet Ihr davon? Ist das nützlich/ würdet Ihr das verwenden
>> (insb. auch in Kombination mit CI)? Wem fallen noch weitere Checks
>> ein, die man implementieren könnte?
>> Auf unserem nächsten Treffen stelle ich das gerne auch mal im Detail
>> vor, zusammen mit reports_as_sparkline.
find_by_sql ist wohl so ne Sache. Kann man schon einbauen denke ich.
Es soll eh noch ein Feature kommen mit dem man bestimmte Checks für
einzelne Directories/ Files ein-/ausschalten kann.
> Ist eigentlich find_by_sql nun guter/schlechter Stil?
> Aber ich würde dazu auf jeden Fall mal gerne Werte sehen.
> (Portierbarkeit auf andere DB, Probleme bei Tabellenumbenennungen oder
> anderen Migrationen... weiss aber nicht ob das grundsätzlich etwas
> über
> die Codequali aussagt - evtl. nur Performancetuning).
> Marco Otte-Witte schrieb:
>> Guter Vorschlag, danke! Das baue ich mal ein.
>> Am 05.08.2009 um 11:43 schrieb Peter Schrammel:
>>> Auch beliebt:
>>> params[xxx], session[xxx] in den views....würg.
>>> Ich werde das nicht auf unseren Code laufen lassen. Es könnte
>>> explodieren oder die Wahrheit ans Licht bringen. ;-)
>>>> Excellent macht Source Code Analyse auf Ruby Code und wendet dabei
>>>> ein
>>>> paar Checks an, die u.A. von roodi, reek und flog übernommen sind,
>>>> bspw:
>>>> Zusätzlich habe ich ein paar Rails-spezifische Checks eingebaut:
>>>> * AttrAccessibleCheck (checkt dass attr_accessible verwendet wird)
>>>> * AttrProtectedCheck (checkt dass attr_protected nicht verwendet
>>>> wird,
>>>> besser Whitelist per attr_accessible)
>>>> * InstanceVarInPartialCheck (checkt dass in Partials keine
>>>> Instanzvariablen verwendet werden, die das Partial abhängig vom
>>>> Controller oder der View machen)
>>>> * ValidationsCheck (checkt dass Models Validations definieren)
>>>> Insbesondere bei den Rails spezifischen Checks sehe ich
>>>> Potential, da
>>>> mit solchen Checks ganz konkrete Probleme und Fehlerquellen erkannt
>>>> werden können. Die allgemeinen Checks zur Komplexität usw. sind ja
>>>> immer nur mögliche Fehlerquellen, Instanzvariablen in Partials aber
>>>> bspw. ganz konkrete Code Smells.
>>>> Was haltet Ihr davon? Ist das nützlich/ würdet Ihr das verwenden
>>>> (insb. auch in Kombination mit CI)? Wem fallen noch weitere Checks
>>>> ein, die man implementieren könnte?
>>>> Auf unserem nächsten Treffen stelle ich das gerne auch mal im
>>>> Detail
>>>> vor, zusammen mit reports_as_sparkline.
> ...wie ich mir genau das gleiche gedacht habe... =)
> Klingt aber gut um unsere Trainees und neue Kollegen zu quälen.
> Mir fallen momentan nur Konventions ein die ich mir gesetzt habe...
> -geschachtelte Verzweigungen wo man eigentlich switchen könnte
> -reserved words, terms, helper etc. (weiß nicht wie oft mir deswegen
> schon n Controller unserer externen um die Ohren geflogen ist)
> -richtige pluralisierung (scheint doch für einige n problem zu sein)
> -richtige und minimal nötige Routen
> -@muh = params[:bla] im view:
> = @muh
> -h() und sanitize, wenigstens wenn obiges
> -proper "css'ing"
> Ist jetzt mal ausm Kopf so das häufigste was mir auffiel.
> Mir fällt noch ne Menge HAML spezifisches ein, ka ob du da überhaupt
> hin
> möchtest.
> Peter Schrammel schrieb:
>> Auch beliebt:
>> params[xxx], session[xxx] in den views....würg.
>> Ich werde das nicht auf unseren Code laufen lassen. Es könnte
>> explodieren oder die Wahrheit ans Licht bringen. ;-)
>>> Excellent macht Source Code Analyse auf Ruby Code und wendet dabei
>>> ein
>>> paar Checks an, die u.A. von roodi, reek und flog übernommen sind,
>>> bspw:
>>> Zusätzlich habe ich ein paar Rails-spezifische Checks eingebaut:
>>> * AttrAccessibleCheck (checkt dass attr_accessible verwendet wird)
>>> * AttrProtectedCheck (checkt dass attr_protected nicht verwendet
>>> wird,
>>> besser Whitelist per attr_accessible)
>>> * InstanceVarInPartialCheck (checkt dass in Partials keine
>>> Instanzvariablen verwendet werden, die das Partial abhängig vom
>>> Controller oder der View machen)
>>> * ValidationsCheck (checkt dass Models Validations definieren)
>>> Insbesondere bei den Rails spezifischen Checks sehe ich Potential,
>>> da
>>> mit solchen Checks ganz konkrete Probleme und Fehlerquellen erkannt
>>> werden können. Die allgemeinen Checks zur Komplexität usw. sind ja
>>> immer nur mögliche Fehlerquellen, Instanzvariablen in Partials aber
>>> bspw. ganz konkrete Code Smells.
>>> Was haltet Ihr davon? Ist das nützlich/ würdet Ihr das verwenden
>>> (insb. auch in Kombination mit CI)? Wem fallen noch weitere Checks
>>> ein, die man implementieren könnte?
>>> Auf unserem nächsten Treffen stelle ich das gerne auch mal im Detail
>>> vor, zusammen mit reports_as_sparkline.
Wohl wahr,
wie ich sagte bin ichn Konventionalist...
Mein Ziel ist es immer so sauber wie möglich, ohne viel Zusatz durch mein Code zu kommen.
Daher wissen das ichs nutzen muss > jemand der mir aufn Kopp haut wenn nich. ;)
(Mal ganz davon abgesehn dass ichs ned kannte, bin ich HAMLer und so wie ichs verstanden hab hängt sich das in rhtml ein)
Ich hab früher auch die Leute gehasst die mir erzählt haben sie können nur mit allow_url_fopen OFF und php_safe_mode ON sicher php coden...
> Wohl wahr,
> wie ich sagte bin ichn Konventionalist...
> Mein Ziel ist es immer so sauber wie möglich, ohne viel Zusatz durch
> mein Code zu kommen.
> Daher wissen das ichs nutzen muss > jemand der mir aufn Kopp haut
> wenn nich. ;)
> (Mal ganz davon abgesehn dass ichs ned kannte, bin ich HAMLer und so
> wie ichs verstanden hab hängt sich das in rhtml ein)
> Ich hab früher auch die Leute gehasst die mir erzählt haben sie
> können nur mit allow_url_fopen OFF und php_safe_mode ON sicher php
> coden...
> Roland Moriz schrieb:
>> Patrick Keller schrieb:
>>> -@muh = params[:bla] im view:
>>> = @muh
>>> -h() und sanitize, wenigstens wenn obiges
|
