so, jetzt mal eine interessante frage für diejenigen, die sich auskennen:
vorgeschichte:
-----------------
seitdem ich meinen php-code neuerdings geordnet aufschreibe (mit schön vielen zeilenumbrüchen, tabs und vor allem: kommentare!), werden die php-dateien größer und das nicht unerheblich im vergleich zu der "wüsten vorzeit".
von der größenordnung her geht es bei mir im moment bei dem reinen geordneten php-code um ca. 600 zeilen pro angezeigter html-seite á 23kb (ein dazugehöriges html-template ist nur ein wenig kleiner. natürlich auch fein sortiert).
grundproblem / frage:
--------------------------
1.script) ein geordneter und ausführlich kommentierter programmcode einer serverseitigen interpretierten sprache wie z.b. php (hoffentlich habe ich jetzt keine fachbegriffe verwechselt (-; )
2.script) das gleiche unkommentiert und platzsparend aufgeschrieben
hat ein server bei der abarbeitung des 1.script ernstzunehmende leistungseinbußen im vergleich zum 2.script? oder schreibe ich mir hier gerade nen wolf zu einem problem, das eigentlich gar keines ist? es geht hier wie bereits erwähnt nicht um vorkompilierbare programmiersprachen. und man stelle sich vor, dass der server bis knapp unter die auslastungsgrenze mit aufrufen dieses scripts versorgt wird (-;
Kommentierter code = große dateien = leistungseinbuße ???
gepostet vor 18 Jahre, 7 Monate von Jackk
gepostet vor 18 Jahre, 7 Monate von p4nk0r
ich denke kommentare werden einfach vom parser uebersprungen.... und ordnen sollte eigentlich keinen einfluss haben.... ausser das du net so schnell am augenkrebs erkrankst
btw: 600 zeilen is net viel... wenn ich dann an meine anfaengerzeit zurueckdenke wo ich ohne templates gearbeitet
damals waren 2k zeilen keine seltenheit
btw: 600 zeilen is net viel... wenn ich dann an meine anfaengerzeit zurueckdenke wo ich ohne templates gearbeitet
damals waren 2k zeilen keine seltenheit
gepostet vor 18 Jahre, 7 Monate von Jackk
ja, das mit dem "überspringen" habe ich mir auch so gedacht. aber wenn man das mal wörtlich nimmt, kann ein computer ja keinen text überspringen. es muss ja irgendwie doch jedes zeichen ausgewertet werden (auch wenn das nur geschieht, um festzustellen, ob der kommentar an dieser stelle schon aufhört).
gepostet vor 18 Jahre, 7 Monate von Crafty-Catcher
Original von Jackk
ja, das mit dem "überspringen" habe ich mir auch so gedacht. aber wenn man das mal wörtlich nimmt, kann ein computer ja keinen text überspringen. es muss ja irgendwie doch jedes zeichen ausgewertet werden (auch wenn das nur geschieht, um festzustellen, ob der kommentar an dieser stelle schon aufhört).
Daraus würde sich die Frage stellen ob // schneller ist als /* */
gepostet vor 18 Jahre, 7 Monate von Störti
Sagfen wir mal so, dass es KEINE Leistungseinbuße ist, wenn man alles vollkommentiert, ist falsch, du hast ja schon selbst gesagt, dass der Parser zumindest bei jedem Zeichen schauen muss, obd er Kommentar zu Ende ist, aber ob das merkbar viel ausmacht, mag ich zu bezweifeln.
Ansonsten: Verwende eAcclerator, dann sind die Kommentare nahezu bedeutungslos.
Ansonsten: Verwende eAcclerator, dann sind die Kommentare nahezu bedeutungslos.
gepostet vor 18 Jahre, 7 Monate von Kampfhoernchen
600 LoC is nu wirlich net viel.
So ab 3000 wirds interessant, ab 10000 spannend, ab 50000 sollte man die Architektur nochmal überdenken.
So ab 3000 wirds interessant, ab 10000 spannend, ab 50000 sollte man die Architektur nochmal überdenken.
gepostet vor 18 Jahre, 7 Monate von Jackk
Original von Kampfhoernchen
600 LoC is nu wirlich net viel.
So ab 3000 wirds interessant, ab 10000 spannend, ab 50000 sollte man die Architektur nochmal überdenken.
ok ok, ich bin ein amateur ...angeber!! :wink:
aber gut, das beruhigt mich jetzt auch ein bisschen, wenn ich ehrlich bin.
gepostet vor 18 Jahre, 7 Monate von p4nk0r
Original von Crafty-Catcher
Daraus würde sich die Frage stellen ob // schneller ist als /* */
das tippen vom // geht auf jedenfall schneller als /* */ das reicht mir eigentlich auch schon ^^
gepostet vor 18 Jahre, 7 Monate von exception
Auf dem Produktivserver wirst du irgendwann eh eaccelerator oder APC oder ähnliches einsetzen.
Die cachen den kompilierten Bytecode (also doch vorkompilieren) und ich bin mir ziemlich sicher, dass im Bytecode keine Kommentare enthalten sind :-)
Von daher ist es für die Performance egal, ob du Kommentare verwendest oder nicht.
Die cachen den kompilierten Bytecode (also doch vorkompilieren) und ich bin mir ziemlich sicher, dass im Bytecode keine Kommentare enthalten sind :-)
Von daher ist es für die Performance egal, ob du Kommentare verwendest oder nicht.
gepostet vor 18 Jahre, 7 Monate von Kampfhoernchen
Außerdem will ichs mal so sagen:
Wenn dir das bisschen Probleme macht, dann würde ich mir lieber über die Architektur der Anwendung gedanken machen
Wenn dir das bisschen Probleme macht, dann würde ich mir lieber über die Architektur der Anwendung gedanken machen
gepostet vor 18 Jahre, 7 Monate von Kallisti
Original von Crafty-Catcher
Daraus würde sich die Frage stellen ob // schneller ist als /* */
Auch bei // musst du noch das newline parsen...
gepostet vor 18 Jahre, 7 Monate von Temruk
Das mit den Kommentaren würde ich eher noch von einer anderen Warte sehen Wir haben bei uns die Vorgabe, dass Kommentare mindestens 30% des Skripts ausmachen müssen und so klar sein müssen, dass ich mein Skript einem fremden Coder gebe und der weiß nach 5 Minuten spätestens was abgeht. Das erfordert eiserne Disziplin aber hilft ungemein. Denn: lass es mal zu einem schwerwiegenden Bug kommen, der Coder ist nicht verfügbar -> muss jemand anderes machen. Wenn das nun fix geht, weil gut kommentiert ersparst du dir viel mehr Nerven und damit auch Kunden und letztenendes Euros, als wenn du sagst sch**** auf die Kommentare macht den Parser schneller 5 Mann mehr aufm Server.
gepostet vor 18 Jahre, 7 Monate von Macavity
rein logsch müsste // schneller als /**/ sein...oder? da der compiler ja weißt aha..die zeile ist ab hier alles kommentar... **** auf den rest. beim anderen muss er halt nach der position des nächsten */ suchen..
...
müsste man wissen ob es vielleicht schneller geht nach der nächsten position von etwas zu suchen ?_? bei mehrzeiligen kommentaren könnte /**/ dann schneller sein.
Ich denke aber auch das du das bisschen Kommentare ignorieren kannst...wenn du nicht grade für jede größere Stelle einen Aufsatz reintippst
...
müsste man wissen ob es vielleicht schneller geht nach der nächsten position von etwas zu suchen ?_? bei mehrzeiligen kommentaren könnte /**/ dann schneller sein.
Ich denke aber auch das du das bisschen Kommentare ignorieren kannst...wenn du nicht grade für jede größere Stelle einen Aufsatz reintippst
gepostet vor 18 Jahre, 7 Monate von Mudder
Ich sag jetzt mal ganz ehrlich: Ich kommentiere nicht.. und wenn dann schreibe ich was das für ne Funktion ist
Sagt wenig aus aber ich finde sowas geordneter als
Funktionsname: setdate()
Attribute: $setting
...
...
...
...
...
*****/
15 Zeilen um eine Funktion zu beschreiben..
.. und @Temruk
Wenn du fremde Scripts anschaust dann wirst du egal ob kommentiert oder nicht erstmal dumm dastehen und dich fragen: Wo ist denn hier der Anfang.
Macht sicher jeder anders doch ich schau mir den Scriptablauf einmal an und gehe den Weg dann entsprechend nach bis ich beim Fehler lande. Die Funktionsdokumentationen stören mich da ehr nur, weil sie oftmals grösser sind als eine 3-Zeilen-Funktion und man ewig scrollen muss (und dadurch ehr Funktionen übersieht). Das die Funktion dazu da ist das sie das Datum formatiert erkenn ich im Normalfall auch auf den ersten Blick im Quellcode bzw. spätestens dann wenn ich den Scriptablauf nachgehe um einen Fehler zu finden.
Nur weil der Code genaustens dokumentiert ist bringt einem das garnix weil es nämlich keinen Funktionsablauf, Klassenkonzept oder ein Inhaltsverzeichniss für die Dateien gibt. Folge: Man muss die Datei einmal durchscrollen und schauen was es für Funktionen gibt und was sie kurz machen.. und da stören mich die Kommentarfluten einfach nur enorm und in der Zeit wo ich mir die Doku durchlese hab ich auch die Funktion durchgeschaut und weiss genauer was diese nun wirklich macht.
// Fügt die aktuelle Uhrzeit im gewünschten Format ein.
Sagt wenig aus aber ich finde sowas geordneter als
/*****
Funktionsname: setdate()
Attribute: $setting
...
...
...
...
...
*****/
15 Zeilen um eine Funktion zu beschreiben..
.. und @Temruk
Wenn du fremde Scripts anschaust dann wirst du egal ob kommentiert oder nicht erstmal dumm dastehen und dich fragen: Wo ist denn hier der Anfang.
Macht sicher jeder anders doch ich schau mir den Scriptablauf einmal an und gehe den Weg dann entsprechend nach bis ich beim Fehler lande. Die Funktionsdokumentationen stören mich da ehr nur, weil sie oftmals grösser sind als eine 3-Zeilen-Funktion und man ewig scrollen muss (und dadurch ehr Funktionen übersieht). Das die Funktion dazu da ist das sie das Datum formatiert erkenn ich im Normalfall auch auf den ersten Blick im Quellcode bzw. spätestens dann wenn ich den Scriptablauf nachgehe um einen Fehler zu finden.
Nur weil der Code genaustens dokumentiert ist bringt einem das garnix weil es nämlich keinen Funktionsablauf, Klassenkonzept oder ein Inhaltsverzeichniss für die Dateien gibt. Folge: Man muss die Datei einmal durchscrollen und schauen was es für Funktionen gibt und was sie kurz machen.. und da stören mich die Kommentarfluten einfach nur enorm und in der Zeit wo ich mir die Doku durchlese hab ich auch die Funktion durchgeschaut und weiss genauer was diese nun wirklich macht.
gepostet vor 18 Jahre, 7 Monate von Drezil
ich stimme Mudder zu.
Allerdings gib es acuh Editoren (ka, aber ich denke Eclipse kann das auch), die aus den kommentaren über einer funktion (wenn sich nach festen regeln definiert sind .. @param, @*bla*) eine komplette map des codes machen können und dann visuell darstellen, wie welche funktionen über was miteinander verknüpft sind.
Gerade bei einem flüchtigen Blick ist das extrem hilfreich..
außerdem mag ich bei meinem eclipse die "hide comments"-option
Aber ansonsten kenne ich auch noch das beste beispiel für überflüssige kommentare (habe ich selbst gesehen):
Allerdings gib es acuh Editoren (ka, aber ich denke Eclipse kann das auch), die aus den kommentaren über einer funktion (wenn sich nach festen regeln definiert sind .. @param, @*bla*) eine komplette map des codes machen können und dann visuell darstellen, wie welche funktionen über was miteinander verknüpft sind.
Gerade bei einem flüchtigen Blick ist das extrem hilfreich..
außerdem mag ich bei meinem eclipse die "hide comments"-option
Aber ansonsten kenne ich auch noch das beste beispiel für überflüssige kommentare (habe ich selbst gesehen):
i++; //increment i
gepostet vor 18 Jahre, 7 Monate von Sarge
i++; //increment i
ist nach standard coding konventionen genauso falsch wie keine kommentare.
Und sobald du es mit mal nichtmehr ganz trivialen Algorithmen zutuen hast will ich sehen das du durchs überfliegen des reinen Codes ne ahnung hast was da eigentlich genau passiert.
Auch sollte jede wichtigere Entwurfsentscheidung dokumentiert werden weil genau das der Code nicht verraten kann.
Bei vollständigen Verzicht auf Kommentare wird dir später im team deine kollegen spätestens dann die Wartungscrew den Arsch aufreisen. Denn es macht kein Spaß wenn du kurz Code überfliegst ahh klar da fehlt ein break; im Switch case #2 .. und dabei ist genau das diesesmal gewollt und kein fehler. (standard beispiel)
Richtige Namensgebung ist vorallem auch verdammt wichtig.
ist nach standard coding konventionen genauso falsch wie keine kommentare.
Und sobald du es mit mal nichtmehr ganz trivialen Algorithmen zutuen hast will ich sehen das du durchs überfliegen des reinen Codes ne ahnung hast was da eigentlich genau passiert.
Auch sollte jede wichtigere Entwurfsentscheidung dokumentiert werden weil genau das der Code nicht verraten kann.
Bei vollständigen Verzicht auf Kommentare wird dir später im team deine kollegen spätestens dann die Wartungscrew den Arsch aufreisen. Denn es macht kein Spaß wenn du kurz Code überfliegst ahh klar da fehlt ein break; im Switch case #2 .. und dabei ist genau das diesesmal gewollt und kein fehler. (standard beispiel)
Richtige Namensgebung ist vorallem auch verdammt wichtig.
gepostet vor 18 Jahre, 7 Monate von knalli
Naja, einige Kommentare sind aber trivial, wenn man (mindestens im Projekt) eine einheitliche und funktional logische Namenskonvention nutzt. Wenn die Variable bsp. durch Präfixnotation (und ich meine jetzt auch die richtige) aussagt, was sie hat und die die Funktion/Methode einen sinnvollen namen hat, braucht man das nicht mehr zu kommentieren. Bei Anwendung von PHP/JavaDoc Style (Kommentare) sind die Möglichkeiten des Nachvollziehens in einer modernen IDE sogar genial - Mauszeiger über die Variable ziehen, und schon poppt ein Infofeld mit Beschreibung ggf Initialwert auf.
Was eine for-Schleife macht, braucht man keinem zu erklären - sinnvoll sind Kommentare natürlich, wenn man komplexere Algorithmen (und alles ist im Endeffekt ein Algorithmus) verwendet - also warum nutze ich (ne, ich nutze gar keine ) diesen bestimmten regulären Ausdruck, was macht diese 4fach geschachtelte For-Schleife nun wirklich - ? Da hilft es auch, die üblicherweise benutzen i,j Inkrementoren durch sinnvollere auszutauschen.
Ideal wäre ein Code, der sich durch das Lesen selber erklärt - man darf vom (neuen) Coder Fachwissen abverlangen - aber er muss auch eine Chance haben.
Was eine for-Schleife macht, braucht man keinem zu erklären - sinnvoll sind Kommentare natürlich, wenn man komplexere Algorithmen (und alles ist im Endeffekt ein Algorithmus) verwendet - also warum nutze ich (ne, ich nutze gar keine ) diesen bestimmten regulären Ausdruck, was macht diese 4fach geschachtelte For-Schleife nun wirklich - ? Da hilft es auch, die üblicherweise benutzen i,j Inkrementoren durch sinnvollere auszutauschen.
Ideal wäre ein Code, der sich durch das Lesen selber erklärt - man darf vom (neuen) Coder Fachwissen abverlangen - aber er muss auch eine Chance haben.
gepostet vor 18 Jahre, 7 Monate von Chojin
Kommentare sind schon sinnvoll, wenn man sie konsequent benutzt.
(Das ist immer lustig wenn eine funktion oder objekt in gut dokumentiertem code auftaucht und niemand zuordnen kann, was das ding macht oder wer es eingebaut hat. )
Ich selbst kommentiere nur wo es nötig ist, also wenn ich eine Funktion/Objekt fertig habe eine kurze Zweckbeschreibung oder wenn ich mir vornehme an einer stelle später noch weiterzuprogrammieren eine notiz zur fehlenden Funktionalität.
Über Performance mach ich mir hierbei wirklich überhauptkeine gedanken mehr... wozu gibt es PHP-Compilier wie eAccelerator und Co? Kann mir schwer vorstellen, dass die Kommentare nach dem Kompilieren noch vorhanden sind... :roll:
reg4rds
chojin
(Das ist immer lustig wenn eine funktion oder objekt in gut dokumentiertem code auftaucht und niemand zuordnen kann, was das ding macht oder wer es eingebaut hat. )
Ich selbst kommentiere nur wo es nötig ist, also wenn ich eine Funktion/Objekt fertig habe eine kurze Zweckbeschreibung oder wenn ich mir vornehme an einer stelle später noch weiterzuprogrammieren eine notiz zur fehlenden Funktionalität.
Über Performance mach ich mir hierbei wirklich überhauptkeine gedanken mehr... wozu gibt es PHP-Compilier wie eAccelerator und Co? Kann mir schwer vorstellen, dass die Kommentare nach dem Kompilieren noch vorhanden sind... :roll:
reg4rds
chojin
gepostet vor 18 Jahre, 7 Monate von knalli
Zugegeben, ich kommentiere auch relativ wenig :S
Ich habe mir aber angewöhnt, wenigstens die Schnittstellen (also Methoden, Funktionen, Variablen sowie Defintionen aka Konstanten zu kommentieren. Da Eclipsebenutzung, bereits ausreichend.
Habe gerade ein gutes Beispiel gefunden: Während des Durcharbeitens meiner neusten Praktikaaufgabe (Java) fürs Studium ist mir eine neue Funktion/Methode aufgefallen, System.arraycopy().
Was die Methode macht, dürfte jedem klar sein, dafür braucht man nicht viel Englisch - ich gehe mit der Maus drüber, wenn ich aus den 2 oberen Zeilen nicht schlau wurde und sehe den Syntax der Schnittstelle - und weiß sofort Bescheid.
Ergo: Schnittstellenkommentare sind noch wichtiger als die Kommentare innen drinnen, denn die interessieren mich im Zweifel nicht. Und: Teilweise erklären sich Funktionen bereits, dann muss ich das Rad nicht "neu beschreiben". Eine grobe Aussage reicht doch dann..
Angewöhnen sollte man sich, meiner Meinung, nur "ungewöhnliche Codestellen", z.B. explizites Casting an einer undurchsichtigen Stelle, ein komplexer Algorithmus oder gar ein TODO! (Manche IDEs vermerken solche Einträge seperat in einer TODO-Liste).
Wegen PHPDoc-Style fällt mir gerade ein: http://phpdoc.org
Wer JavaDoc kennt, wird es wiedererkennen
PS: Ich suche noch immer ein (Eclipse)plugin, welches PHPDoc ähnlich JavaDoc direkt über Kommendozeile analysiert - ohne den Umweg eines Webservers..
Ich habe mir aber angewöhnt, wenigstens die Schnittstellen (also Methoden, Funktionen, Variablen sowie Defintionen aka Konstanten zu kommentieren. Da Eclipsebenutzung, bereits ausreichend.
Habe gerade ein gutes Beispiel gefunden: Während des Durcharbeitens meiner neusten Praktikaaufgabe (Java) fürs Studium ist mir eine neue Funktion/Methode aufgefallen, System.arraycopy().
Was die Methode macht, dürfte jedem klar sein, dafür braucht man nicht viel Englisch - ich gehe mit der Maus drüber, wenn ich aus den 2 oberen Zeilen nicht schlau wurde und sehe den Syntax der Schnittstelle - und weiß sofort Bescheid.
Ergo: Schnittstellenkommentare sind noch wichtiger als die Kommentare innen drinnen, denn die interessieren mich im Zweifel nicht. Und: Teilweise erklären sich Funktionen bereits, dann muss ich das Rad nicht "neu beschreiben". Eine grobe Aussage reicht doch dann..
Angewöhnen sollte man sich, meiner Meinung, nur "ungewöhnliche Codestellen", z.B. explizites Casting an einer undurchsichtigen Stelle, ein komplexer Algorithmus oder gar ein TODO! (Manche IDEs vermerken solche Einträge seperat in einer TODO-Liste).
Wegen PHPDoc-Style fällt mir gerade ein: http://phpdoc.org
Wer JavaDoc kennt, wird es wiedererkennen
PS: Ich suche noch immer ein (Eclipse)plugin, welches PHPDoc ähnlich JavaDoc direkt über Kommendozeile analysiert - ohne den Umweg eines Webservers..
gepostet vor 18 Jahre, 7 Monate von woodworker
http://pear.php.net/package/PhpDocumentor
http://www.stack.nl/~dimitri/doxygen/
also das wären 2 sachen die das halt interpretieren
http://www.stack.nl/~dimitri/doxygen/
also das wären 2 sachen die das halt interpretieren
gepostet vor 18 Jahre, 7 Monate von Krisch
Also jeder Compiler / Parser geht in 3 Schritten vor:
1. Einlesen
2. Interpretieren
3. Ausführen
Natürlich hängt es vom Compiler / Parser ab, wie schnell das durchgeführt wird, aber ich gehe mal davon aus, dass die meisten schlau genug sind Kommentare schon beim Einlesen zu überspringen.
Das Einlesen macht nur einen sehr kleinen Teil aus, die Hauptleistung entsteht in den anderen beiden Phasen. Also schreib so viele Kommentare wie du willst, die Geschwindigkeit wird dadurch nur wenig beeinflußt.
@Macavity:
Ich glaub nicht, dass es Unterschiede bei den Kommentarfunktionen gibt. Im Rechner gibt es keinen Zeilenumbruch, man muss trotzdem die ganze Zeile durchgehen um das Zeilenumbruch-Symbol zu finden.
1. Einlesen
2. Interpretieren
3. Ausführen
Natürlich hängt es vom Compiler / Parser ab, wie schnell das durchgeführt wird, aber ich gehe mal davon aus, dass die meisten schlau genug sind Kommentare schon beim Einlesen zu überspringen.
Das Einlesen macht nur einen sehr kleinen Teil aus, die Hauptleistung entsteht in den anderen beiden Phasen. Also schreib so viele Kommentare wie du willst, die Geschwindigkeit wird dadurch nur wenig beeinflußt.
@Macavity:
Ich glaub nicht, dass es Unterschiede bei den Kommentarfunktionen gibt. Im Rechner gibt es keinen Zeilenumbruch, man muss trotzdem die ganze Zeile durchgehen um das Zeilenumbruch-Symbol zu finden.
gepostet vor 18 Jahre, 6 Monate von Macavity
Eine Sache ist mir letztens passiert die mich etwas verwirrt hat ...
Ich dachte bisher (und ich arbeite nun schon eine gute Zeit lang mit php und c++) das der Compiler alles in der gleichen Zeile nach einem "//" als Kommentar ansieht.
Ganz offensichtlich ist das nicht der Fall. Zumindest nicht ausschließlich
von dieser Regel ausgeschlossen ist logischerweise ein Ende des PHP-Blocks durch ?>
aber interessanterweise führt das auch zu einem problem:
echo "asdf"; // echo "var x=0;";
Das tolle ist das "" scheinbar auch den Kommentar beendet.
Kann mir jemand den höheren Sinn davon erklären?
Ich dachte bisher (und ich arbeite nun schon eine gute Zeit lang mit php und c++) das der Compiler alles in der gleichen Zeile nach einem "//" als Kommentar ansieht.
Ganz offensichtlich ist das nicht der Fall. Zumindest nicht ausschließlich
von dieser Regel ausgeschlossen ist logischerweise ein Ende des PHP-Blocks durch ?>
aber interessanterweise führt das auch zu einem problem:
echo "asdf"; // echo "var x=0;";
Das tolle ist das "" scheinbar auch den Kommentar beendet.
Kann mir jemand den höheren Sinn davon erklären?
gepostet vor 18 Jahre, 6 Monate von TheUndeadable
Kommt evtl von der
$x = bla;
-Darstellung
ich persönlih fände es aber etwas inkonsequent, wenn man mischen könnte.
$x = bla;
-Darstellung
ich persönlih fände es aber etwas inkonsequent, wenn man mischen könnte.
gepostet vor 18 Jahre, 6 Monate von Macavity
ah stimmt...das gibts ja auch noch...so ein quark... gibt es leute die das benutzen?
gepostet vor 18 Jahre, 6 Monate von Fornax
Ich denke nicht. Ich selber habe es nie benutzt, und werde es nie benutzen, da ich es sonst mit Javascript verwechsle
gepostet vor 18 Jahre, 6 Monate von TheUndeadable
Ich habe es genutzt ;-)
Eigentlich nur aus einem Grund: Frontpage bzw der Nachfolger Visual Studio kann mit besser umgehen als mit
Eigentlich nur aus einem Grund: Frontpage bzw der Nachfolger Visual Studio kann mit besser umgehen als mit
gepostet vor 18 Jahre, 6 Monate von Macavity
ernsthaft...es gibt entwickler die Frontpage nutzen? oder genutzt haben... naja..jedem das seine.
gepostet vor 18 Jahre, 6 Monate von TheUndeadable
Naja, etwas offtopic und mein letzter Kommentar dazu:
Frontpage um sich schnell eine Seite zusammenzukloppen und dann per TextPad zu perfektionieren. Hat sich zumindest bei mir gut bewährt. Gerade bei komplizierteren Tabellendesigns behält man einen guten Überblick über die Seite. Gemacht hatte ich es übrigens um 2002, da gab es kaum bessere Programme. Das hält sich bei mir bis heute.
Frontpage um sich schnell eine Seite zusammenzukloppen und dann per TextPad zu perfektionieren. Hat sich zumindest bei mir gut bewährt. Gerade bei komplizierteren Tabellendesigns behält man einen guten Überblick über die Seite. Gemacht hatte ich es übrigens um 2002, da gab es kaum bessere Programme. Das hält sich bei mir bis heute.
gepostet vor 18 Jahre, 6 Monate von Kampfhoernchen
Eigentlich kann man auch gleich die ASP-Tags verwenden
<% %>
Vielleicht gibts da auch nen Sinn?
<% %>
Vielleicht gibts da auch nen Sinn?
gepostet vor 18 Jahre, 6 Monate von Amun Ra
Ich belebe den Thread einfach nochmal...
Hatte lokal ein paar Probleme bei XAMPP 1.5.1 mit PHP 5.1.1 und dem eAccelerator.
Na ja jetzt funzt auf jeden Fall alles, aber beim durchsehen der gecacheten eAccelerator Dateien ist mir was aufgefallen...
Es werden auf jeden Fall Kommentare gecached, allerdings scheinbar nur solche:
* wird gecached
*
*/
In diesen Formen werden sie scheinbar übergangen:
* wird nicht gecached
*
*****/
/*
* wird nicht gecached
*
*/
/* wird nicht gecached */
// wird nicht gecached
# wird nicht gecached
Also die typischen PHPDocumentor Kommentare.
Da find ichs direkt gut das ich die nicht nutze...
Auch wenn das Standardscripts nicht ausbremsen wird,
find ichs doch interessant zu wissen.
Hatte lokal ein paar Probleme bei XAMPP 1.5.1 mit PHP 5.1.1 und dem eAccelerator.
Na ja jetzt funzt auf jeden Fall alles, aber beim durchsehen der gecacheten eAccelerator Dateien ist mir was aufgefallen...
Es werden auf jeden Fall Kommentare gecached, allerdings scheinbar nur solche:
/**
* wird gecached
*
*/
In diesen Formen werden sie scheinbar übergangen:
/*****
* wird nicht gecached
*
*****/
/*
* wird nicht gecached
*
*/
/* wird nicht gecached */
// wird nicht gecached
# wird nicht gecached
Also die typischen PHPDocumentor Kommentare.
Da find ichs direkt gut das ich die nicht nutze...
Auch wenn das Standardscripts nicht ausbremsen wird,
find ichs doch interessant zu wissen.
gepostet vor 18 Jahre, 6 Monate von moLTe
Hi,
also ich nutze Kommentare sehr häufig, damit kann man so schön seine debug Informationen auskommentieren. Wenn es dann zu Fehlern kommt hat man meistens an den relevanten Stellen schon die wichtigen Variablen zur Hand, brauch nur noch // wegnehmen und hat wieder seine Infos.
Ansonsten schreibe ich ungern Kommentare, aber mehr so aus Faulheit.
In Fremden Scripten sind sie manchmal brauchbar, aber >meistens< ist der Code Kommentar genug :wink:
mfg
moLTe
also ich nutze Kommentare sehr häufig, damit kann man so schön seine debug Informationen auskommentieren. Wenn es dann zu Fehlern kommt hat man meistens an den relevanten Stellen schon die wichtigen Variablen zur Hand, brauch nur noch // wegnehmen und hat wieder seine Infos.
Ansonsten schreibe ich ungern Kommentare, aber mehr so aus Faulheit.
In Fremden Scripten sind sie manchmal brauchbar, aber >meistens< ist der Code Kommentar genug :wink:
mfg
moLTe
gepostet vor 18 Jahre, 6 Monate von Kampfhoernchen
Dann guck dir mal nen etwas komplexeren Algorithmus von dir selbst n halbes Jahr lang nicht an. Und dann versuch nachzuvollziehen, was du da gemacht hast.
Einmal mit Kommentaren und einmal ohne. Um den unkommentierten Code zu verstehen, brauchst du mind. 3 mal so lang wie für den kommentieren.
Einmal mit Kommentaren und einmal ohne. Um den unkommentierten Code zu verstehen, brauchst du mind. 3 mal so lang wie für den kommentieren.
gepostet vor 18 Jahre, 6 Monate von Mudder
Du hast sicher irgendwo recht.. doch irgendwo auch nicht.
Bei "normalen" Klassen dürfte es sich ehr wenig nehmen ob man einmal die Klasse durchscrollt und Funktion für Funktion schaut was da eigentlich passiert oder ob man Funktion für Funktion die Doku durchliesst. Damit man die Klasse dann verstanden hat, da muss die Doku dann schon bischel mehr sein als nur "Gibt die Variable X aus" und bei umfangreichen Dokus ist man mitunter schneller wenn man sich die Funktion einfach anschaut. (und wenns schneller ist weil man für eine Zeile informativer Doku, 5 Zeilen mit Sternchen und "hochinformativen" Variablenauflistungen mitlesen muss)
Bei "normalen" Klassen dürfte es sich ehr wenig nehmen ob man einmal die Klasse durchscrollt und Funktion für Funktion schaut was da eigentlich passiert oder ob man Funktion für Funktion die Doku durchliesst. Damit man die Klasse dann verstanden hat, da muss die Doku dann schon bischel mehr sein als nur "Gibt die Variable X aus" und bei umfangreichen Dokus ist man mitunter schneller wenn man sich die Funktion einfach anschaut. (und wenns schneller ist weil man für eine Zeile informativer Doku, 5 Zeilen mit Sternchen und "hochinformativen" Variablenauflistungen mitlesen muss)
gepostet vor 18 Jahre, 6 Monate von Kallisti
Man kommentiert ja auch nur warum man etwas tut, nicht was man tut. Das zeigt der Code selbst.
gepostet vor 18 Jahre, 6 Monate von Amun Ra
Wie auch immer man kommentiert...
eAccelerator 0.9.4 cached diese Kommentare teilweise,
je nach dem wie und wo sie geschrieben wurden.
Bei APC weiss ichs nicht.
Mal n Erfahrungsbericht: ich nutze ein kleines Opensource CMS...
Die admin.class.php enthält alles was man zum administrieren braucht
und war original mit Kommetaren und Einrückungen 92 Kb gross.
Ich habe alle Kommtare entfernt und den gesamten Code nach
links eingerückt ( class und function auf einer Ebene ).
Am Ende war die Datei schlanke 66 Kb gross !!!
Mein Fazit: Kommentare und schöner Code ja, aber in Massen !
Ich denke das es schon etwas ausmacht ob PHP 92 Kb
oder nur 66 Kb einlesen muss...
eAccelerator 0.9.4 cached diese Kommentare teilweise,
je nach dem wie und wo sie geschrieben wurden.
Bei APC weiss ichs nicht.
Mal n Erfahrungsbericht: ich nutze ein kleines Opensource CMS...
Die admin.class.php enthält alles was man zum administrieren braucht
und war original mit Kommetaren und Einrückungen 92 Kb gross.
Ich habe alle Kommtare entfernt und den gesamten Code nach
links eingerückt ( class und function auf einer Ebene ).
Am Ende war die Datei schlanke 66 Kb gross !!!
Mein Fazit: Kommentare und schöner Code ja, aber in Massen !
Ich denke das es schon etwas ausmacht ob PHP 92 Kb
oder nur 66 Kb einlesen muss...
gepostet vor 18 Jahre, 6 Monate von Mudder
@Kallisit: Schön wärs..
Schaut euch mal smarty an.. ( http://smarty.php.net/do_download.php?download_file=Smarty-2.6.13.tar.gz )
z.B. die Datei smarty.class.php
* This is the resource type to be used when not specified
* at the beginning of the resource path. examples:
* $smarty->display('file:index.tpl');
* $smarty->display('db:index.tpl');
* $smarty->display('index.tpl'); // will use default resource type
* {include file="file:index.tpl"}
* {include file="db:index.tpl"}
* {include file="index.tpl"} {* will use default resource type *}
*
* @var array
*/
var $default_resource_type = 'file';
12 Zeilen Kommentar für eine Zeile Code..
* Registers compiler function
*
* @param string $function name of template function
* @param string $function_impl name of PHP function to register
*/
function register_compiler_function($function, $function_impl, $cacheable=true)
{
$this->_plugins['compiler'][$function] =
array($function_impl, null, null, false, $cacheable);
}
Wieder 6 Zeilen Kommentar für 5 Zeilen Code.. und so sieht im Grunde die ganze Datei aus..
Die ganze Klasse hat 1944 Zeilen, doch man könnte diese mit Sicherheit um die Hälfte kürzen!
Und diese Beschreibungsromane sind der offizielle "Standard".. und dennoch beschreiben diese Kommentare bestenfalls die zu übergebenen Variablen aber nicht die Funktion.. Sorry aber bei solchen Standards kann ich gut auf die Kommentare verzichten. Kilometerweit scrollen und die Funktion suchen muss man so oder so.
Schaut euch mal smarty an.. ( http://smarty.php.net/do_download.php?download_file=Smarty-2.6.13.tar.gz )
z.B. die Datei smarty.class.php
/**
* This is the resource type to be used when not specified
* at the beginning of the resource path. examples:
* $smarty->display('file:index.tpl');
* $smarty->display('db:index.tpl');
* $smarty->display('index.tpl'); // will use default resource type
* {include file="file:index.tpl"}
* {include file="db:index.tpl"}
* {include file="index.tpl"} {* will use default resource type *}
*
* @var array
*/
var $default_resource_type = 'file';
12 Zeilen Kommentar für eine Zeile Code..
/**
* Registers compiler function
*
* @param string $function name of template function
* @param string $function_impl name of PHP function to register
*/
function register_compiler_function($function, $function_impl, $cacheable=true)
{
$this->_plugins['compiler'][$function] =
array($function_impl, null, null, false, $cacheable);
}
Wieder 6 Zeilen Kommentar für 5 Zeilen Code.. und so sieht im Grunde die ganze Datei aus..
Die ganze Klasse hat 1944 Zeilen, doch man könnte diese mit Sicherheit um die Hälfte kürzen!
Und diese Beschreibungsromane sind der offizielle "Standard".. und dennoch beschreiben diese Kommentare bestenfalls die zu übergebenen Variablen aber nicht die Funktion.. Sorry aber bei solchen Standards kann ich gut auf die Kommentare verzichten. Kilometerweit scrollen und die Funktion suchen muss man so oder so.
gepostet vor 18 Jahre, 6 Monate von knalli
Nein, muss man nicht. Das ganze macht natürlich nur Sinn, wenn man eine geeignete IDE und/oder Tools wie PHPDocumentor nutzt.
Das geht in den Bereich der Schnittstellenkommentare, und in Java ist das das A und O.
Du musst als Programmierer eh nur wissen, wofür die Funktion/Methode da ist, was sie braucht (Eingabeparamater) und was sie ggf zurückwirft (auch Exceptions, etc). Alles andere (wie genau funktioniert sie) ist zweitrangig und steht wenn überhaupt erst im beschreibendem Teil des Kommentars.
Standards haben des Öfteren die Eigenschaft, das sie meist unnötig komplex erscheinen - warum muss ich denn bei jeder HTML-Datei noch dieses schreiben? Kann ich doch weglassen, jeder weiß doch, das ich html habe.. spart auf Dauer viel, viel Platz...
Das geht in den Bereich der Schnittstellenkommentare, und in Java ist das das A und O.
Du musst als Programmierer eh nur wissen, wofür die Funktion/Methode da ist, was sie braucht (Eingabeparamater) und was sie ggf zurückwirft (auch Exceptions, etc). Alles andere (wie genau funktioniert sie) ist zweitrangig und steht wenn überhaupt erst im beschreibendem Teil des Kommentars.
Standards haben des Öfteren die Eigenschaft, das sie meist unnötig komplex erscheinen - warum muss ich denn bei jeder HTML-Datei noch dieses schreiben? Kann ich doch weglassen, jeder weiß doch, das ich html habe.. spart auf Dauer viel, viel Platz...
gepostet vor 18 Jahre, 6 Monate von Kallisti
Diese Kommentare sind ja auch dafuer da eine definierte Api ueber einen Dokumentationsstandard zu haben... du liest dir perldoc Kommentare auch mit perldoc und nicht im Source durch. Es geht, aber es ist halt nicht huebsch. Gleiches gilt fuer javadoc und eben das hier..
gepostet vor 18 Jahre, 6 Monate von Sarge
Man sollte z.b. mal bedenken das die gesamte java-dokumentation über die integrierte kommentare erstellt worden ist. Alleine da sieht man wie mächtig richtige Dokumentation sein kann...
Und was das feilschen um ein paar KB geht.. man kanns auch übertreiben
Sobald euer projekt größer wird und vorallem mehr leute dran arbeiten werdet ihr um jede _richtige_ dokumentation froh sein. Vorallem wenn ihr schon wieder an was anderem arbeitet und dann nochmal was im alten code ausbessern müsst.
Und was das feilschen um ein paar KB geht.. man kanns auch übertreiben
Sobald euer projekt größer wird und vorallem mehr leute dran arbeiten werdet ihr um jede _richtige_ dokumentation froh sein. Vorallem wenn ihr schon wieder an was anderem arbeitet und dann nochmal was im alten code ausbessern müsst.
gepostet vor 18 Jahre, 6 Monate von Progralixx
Ich bin auch der Meinung, dass es ohne Dokumentation nicht geht. Mein Code besteht manchmal bis zu 40% (grob geschätzt) aus Kommentaren.
In meiner Anfangszeit habe ich die Wirkung und den Zweck kommentierter Zeilen sehr unterschätzt. Jetzt setze ich Kommentare ein, wo immer es geht.
In meiner Anfangszeit habe ich die Wirkung und den Zweck kommentierter Zeilen sehr unterschätzt. Jetzt setze ich Kommentare ein, wo immer es geht.