[Cologne-pm] Hash von Hash von Array???

Michael Lamertz mike at lamertz.net
Mon Mar 1 03:14:34 CST 2004


On Mon, Mar 01, 2004 at 02:38:15AM +0100, A. Pagaltzis wrote:
> > Warum nicht gleich alles durch !expand laufen lassen?  Dann
> > kann es keine Tab-Einstellung kaputt machen ...
> 
> Gerade diese Nötigkeit will ich dadurch vermeiden, dass ich Tabs
> nur zur Einrückung und nicht zur vertikalen Aufreihung verwende.
> 
> Und auch hier wieder: egal, mit welchem -t $TABSTOP du expand(1)
> fütterst, es sieht korrekt aus; würde ich Tabs uns Spaces
> mischen, müsstest du meine Settings raten damit expand daraus
> keinen Kindergeburtstag macht.

Oder Du laesst einfach die Tabs wie Gott sie gewollt hatte *floet* ;)

> Ich finde sie für diesen Fall schicht überflüssig; mehr als ts=4
> stünde nicht drin, aber es liegt mir fern, anderen 4 Spalten als
> Einrückungsbreite vorzuschreiben.

...und...
> Wenn ich Quellcode von jemand anders bearbeiten soll, und da
> Perl-Code in .t-Dateien dabei ist, darf da gerne ein "vim: ft=perl"
> drinstehen. Wird mir aber auf die Tour in den Tabbing-Einstellungen
> herumgefuhrwerkt, würde ich furchtbar böse und würde als erstes mit
> einem global search/replace sämtliche Modelines rausschmeissen.

verwirren mich ein Wenig.  Du willst niemandem ts=4 vorschreiben,
wuerdest aber seinen code "aufraeumen"?

Ist da vielleicht jemand nicht ganz teamfaehig?

> Freundlichkeit bedeutet, es dem anderen zu überlassen, wie er sich etwas
> zu Gemüte führen will, und genau diesem Zweck dient mein Stil. Wenn du
> dir meinen Code ansiehst, sind meine konkreten Einstellungen für dich
> irrelevant; spätestens nach einem expand(1)-Lauf mit von dir gewählter
> Tab-Breite sieht der Code so aus wie *du* es vorziehst.

Nutzerfreundlichkeit macht sich primaer erstmal an sinnvollen Defaults
fest.  

    realy_long_key => 1
             width => 2

Schau Du Dir das obige Beispiel an (/me stellt sich gerade vor, wie
Aristoteles sich einen Wolf auf der Spacetaste tippt weil ja vor 'width'
Spaces gehoeren).  Du machst hier bei der Formatierung den zwingenden
Unterschied zwischen Tabs und Spaces, und dieser Unterschied ist i.d.
Regel unsichtbar, was zur Konsequenz hat, dass Du ueberhaupt nicht
weisst, ob Dein Code Deinem eigenen Regelwerk genuegt oder nicht,
solange Du nicht selber die Tabwith 'mal testweise umgestellt hast, oder
perltidy 'drauf losgelassen hast.

IMO ist das ganze Tab-Problem ein no-prob.  Man laesst die Dinger so wie
sie sind, und alles andere funktioniert automagisch.  Wenn jemand an
meinem Kram basteln will, dann soll er sich entweder an meine Stil
halten oder forken.  Und wenn's um Teamarbeit geht, dann sollten die
Sourcen am besten mit 'default' perltidy-Settings in's CVS, so dass auch
derjenige der 'mal mit Notepad oder cat 'draufschauen moechte
einigermassen lesbaren Code bekommt.  Und zwischen den Checkins kann
jeder Entwickler tabstoppen oder einruecken wie er will.

Mannn!  Man definiert ja auch nicht 'mal so eben die breite des Zeichens
'v' um.  Full-Stop.

Mike

-- 
	    Well, then let's give that Java-Wussie a beating... (me)

Michael Lamertz                        |     +49 2234 204947 / +49 171 6900 310
Sandstr. 122                           |                       mike at lamertz.net
50226 Frechen                          |                 http://www.lamertz.net
Germany                                |               http://www.perl-ronin.de 



More information about the Cologne-pm mailing list