Deine Abneigung gegen Akademiker ist bekannt (wenngleich ich nie so respektlos über Menschen spreche, selbst wenn ich sie nicht leiden kann - wo sind eigentlich die Blockwarte, die mich für deutlich weniger geschlachtet haben, jetzt???) - ich kommentiere schon immer vor der Anweisung statt dahinter.Daniel hat geschrieben:Sehe ich genauso.
Typischer Studenten-Pfusch!
An sich überfällig, aber da ich ohnehin grundsätzlich in der Sprache kommentiere, in der ich auch programmiere (also englisch )....ewx hat geschrieben:Quelle: https://help.sap.com/http.svc/rc/abapdo ... ap_doc.htm
Folgende Benutzer bedankten sich beim Autor Daniel für den Beitrag:
DeathAndPain
Umm... nicht alles, was hinkt, ist ein Vergleich. Schnittstellenbeschreibungen sind mehrzeilig. Kommentare, die mit " eingeleitet werden, sind (typischerweise im Gegensatz zu solchen, die mit * eingeleitet werden) einzeilig, denn das " ist ja gerade dazu da, den Kommentar in dieselbe Zeile hinter den Quellcode setzen zu können, was mit * nicht geht!Ralf hat geschrieben:So wie der Schnittstellenkommentar für den FuBau vor dem FuBau-Coding kommt und der Include-Kommentar ebenfalls zu Beginn des Include steht, finde ich das nur folgerichtig.
Wieso muss sie das? Wenn ich etwas Neues einführe, dann muss es doch nicht zu alten Releasevarianten passen? Die Neuerung kann man schrittweise an allen wichtigen Stellen einführen. Es verlangt doch auch keiner, dass ABAP Doc fit für Release 7.00 gemacht wird.Vielleicht gab es technische Gründe, das erst so spät zu machen. Die SAP hat etwa 250 Releasevarianten, jede Änderung muss zu jeder dieser Varianten passen.
Bei der Umsetzung mag das so sein, aber bei den Designentscheidungen muss jemand den Hut aufhaben und die in die richtige Richtung steuern. Dafür braucht es nicht viele Köpfe, im Gegenteil, da verderben zu viele Köche wahrscheinlich eher den Brei. Erst wenn fertig vorgegeben ist, wie sich ABAP Doc verhalten soll, was man problemlos in kleiner Runde entscheiden kann (da langt wahrscheinlich ein einziges Meeting), dann muss man Teams koordinieren, um den Parser zu entwickeln und ein definitionsgemäßes Verhalten desselben zu erreichen. Dann erst gibt es die Schwierigkeiten, von denen Du redest.Wer frei ist von Fehlern, der werfe.... -- Wenn man mal ein Team nur einem halben Dutzend Leuten koordiniert hat (also wirklich koordiniert mit Vorgaben und Abnahmen und so weiter), der weiß, wie schwierig das ist.
Soweit es um Umlaute geht, könnte ich das noch nachvollziehen, wobei die schon immer unterstützt worden sind, so dass es rückschrittlich wäre, das auf einmal nicht mehr zu tun. Wie gesagt, in den 3er-Releases (bis einschließlich 3.1i) durfte man Umlaute sogar in Feldnamen verwenden. Dass das hinten runtergefallen ist, ist schade, aber nicht weiter dramatisch, aber Sonderzeichen wie Ungleichheitszeichen braucht man in jeder Sprache. Die mit &fghtbuhxfdkg maskieren zu müssen ist bei einem heutigen System schon eine Frechheit. Immerin scheint die SAP das inzwischen begriffen zu haben.PS: Dass deutsche oder anderssprachige Sonderzeichen im Coding die SAP zuletzt interessieren, wundert mich nicht wirklich....
Nein, der wesentliche Vorteil von "-Kommentaren ist nicht, dass man sie hinter die Anweisungen schreiben kann, sondern dass sie vom PP eingerückt werden.DeathAndPain hat geschrieben:denn das " ist ja gerade dazu da, den Kommentar in dieselbe Zeile hinter den Quellcode setzen zu können, was mit * nicht geht!
Natürlich muss das zu allen Releasevarianten passen.DeathAndPain hat geschrieben:Wieso muss sie das? Wenn ich etwas Neues einführe, dann muss es doch nicht zu alten Releasevarianten passen? Die Neuerung kann man schrittweise an allen wichtigen Stellen einführen. Es verlangt doch auch keiner, dass ABAP Doc fit für Release 7.00 gemacht wird.
Im Kommentar? Fakt ist, dass es bisher keinen Grund gab, das ABAP-Coding (!) im Unicode-Format zu speichern. Ich möchte mir gar nicht ausmalen, welcher Aufwand dahintersteckt. Man konnte ja alle Sonderzeichen verwenden, jetzt muss es halt interpretiert werden. Das ist das Neue.DeathAndPain hat geschrieben:Dass das hinten runtergefallen ist, ist schade, aber nicht weiter dramatisch, aber Sonderzeichen wie Ungleichheitszeichen braucht man in jeder Sprache.
Das sehe ich anders. Es wäre auch keine ausreichende Rechtfertigung für zwei unterschiedliche Symbole zur Einleitung von Kommentar. Wenn es nur darum ginge, wäre es besser gewesen, den PP entsprechend fitter zu machen, damit er das auch bei * hinbekommt.Nein, der wesentliche Vorteil von "-Kommentaren ist nicht, dass man sie hinter die Anweisungen schreiben kann, sondern dass sie vom PP eingerückt werden.
Dann brauchste keine Releasevarianten mehr; dann machste ein großes Release, mit dem alle arbeiten. Sofern Du mit "Releasevarianten" unterschiedliche Geschmacksrichtungen von SAP meinst, bin ich noch bereit, Dir recht zu geben, wobei sich alle diese Varianten entsprechend anpassen lassen sollten. Bei Neueinführung eines Werkzeugs wie ABAP Doc sehe ich keine Notwendigkeit, weshalb die Verfügbarkeit in allen Varianten am gleichen Tag bereitgestellt werden muss. Wenn das hier sofort geht und dort zwei Monate später, dann ist das wunderbar okay. Also ist es kein Problem, wenn das von unterschiedlichen Teams umgesetzt wird. Nur die Sollvorgabe, die sollte einheitlich sein und in einer zentralen Besprechung abgesegnet werden, bevor mit der Umsetzung begonnen wird.Natürlich muss das zu allen Releasevarianten passen.
Das kommt durchaus vor. Ein denkbares Beispiel wäre beispielsweise:Im Kommentar?aber Sonderzeichen wie Ungleichheitszeichen braucht man in jeder Sprache.
Code: Alles auswählen.
IF BEGDA < SY-DATUM. " ENDDA > SY-DATUM gilt hier immer; das brauchen wir nicht mehr abzuprüfen
Das spielt keine Rolle. Der ABAP-Compiler ist in der Lage, das Zeichen ">" richtig zu interpretieren, und nicht erst seit gestern. Es wird also schon seit jeher richtig gespeichert. Die einzige neue Anforderung ist, dass keine Grütze daraus wird, wenn es von ABAP Doc interpretiert wird. Da ABAP Doc brandneu ist, sollte das keine nennenswerte Hürde darstellen, da man es gleich richtig implementieren kann.Fakt ist, dass es bisher keinen Grund gab, das ABAP-Coding (!) im Unicode-Format zu speichern.
Dumme Sprüche haben noch nie getaugt, Argumente zu ersetzen.Ich bin erstaunt, wie viele sich hier hinstellen und alles besser gemacht hätten. In der Regel Menschen ohne Personal- oder Systemverantwortung und oft Menschen, die noch nie ein größeres Team geleitet haben. Warum haben diese Leute nicht selbst eine Softwarefirma gegründet um jetzt Millionäre zu sein?
Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
Daniel
Wäre das so einfach, würde die SAP das tun. Es gibt aber verschiedene Kombinationen von Industry Solutions, die miteinander in jeder Kombination harmonieren müssen. Es gibt kein "großes Release", in dem alles drin ist (und dafür gibt es gute Gründe, weil es widersprüchliche Entwicklungen gibt), das wird erst mit S/4 aufgelöst, weil man da eh grundsätzlich aufarbeitet. Man kriegt ein EWM nicht "einfach so" in ein Standard SAP integriert.DeathAndPain hat geschrieben:Dann brauchste keine Releasevarianten mehr; dann machste ein großes Release, mit dem alle arbeiten.Natürlich muss das zu allen Releasevarianten passen.
Ganz besonders dumm sind solche Sprüche wenn manDeathAndPain hat geschrieben:Dumme Sprüche haben noch nie getaugt, Argumente zu ersetzen.Ich bin erstaunt, wie viele sich hier hinstellen und alles besser gemacht hätten. In der Regel Menschen ohne Personal- oder Systemverantwortung und oft Menschen, die noch nie ein größeres Team geleitet haben. Warum haben diese Leute nicht selbst eine Softwarefirma gegründet um jetzt Millionäre zu sein?
Schön langsam, das habe ich so nie gesagt.ralf.wenzel hat geschrieben:Nachtrag: Klar kann man sich hinstellen "alles idiotisches und nichtsnutziges Studentenpack"
Auch die ständige Diskutiererei ohne Ergebnis ist etwas wasralf.wenzel hat geschrieben:Ich habe gerade ein Projekt, wo die Zahl der Meetings massiv reduziert wurde, weil keiner mehr zum Arbeiten kam.
Fragt sich nur, was Du unter "Harmonieren" verstehst. Daten austauschen und mit dem Datenformat des jeweils anderen auskommen, ok. Aber wenn das eine System eine Quellcodedokumentation mittels ABAP Doc unterstützt und das andere nicht, dann wird das den Produktivbetrieb ganz sicher nicht zum Erliegen bringen. Erst recht dann nicht, wenn Du auf beiden den gleichen Quellcode einsetzen kannst, da ABAP Doc syntaktisch abwärtskompatibel ist.Wäre das so einfach, würde die SAP das tun. Es gibt aber verschiedene Kombinationen von Industry Solutions, die miteinander in jeder Kombination harmonieren müssen.
Mit dem Argument bist Du auf der völlig falschen Schiene. Wir sprachen hier über ABAP Doc, und über solche Elemente in ABAP muss man nicht erdballumspannend diskutieren. Da muss es jemanden geben, der federführend ist, Horst Keller oder wer auch immer. Der macht sich Gedanken, was man Neues in ABAP einbauen könnte, hat die Idee von ABAP Doc und macht dann mit seinen wichtigen Leuten ein einziges reales oder virtuelles Meeting. In diesem werden die Fürs und Widers der einen oder andere Umsetzung ausgetauscht, und dann steht eine Spezifikation, die umzusetzen ist. Wenn man danach noch ein Meeting braucht, dann allenfalls, weil irgendwas an der Spezifikation nicht klar genug ist. Meist wird es in solch Fall sogar langen, Horst Keller rasch anzurufen oder die Frage per Email zu klären.Da sitzen Entwickler in der ganzen Welt, die in virtuellen Teams zusammenarbeiten und die auch nicht immer jeden Tag miteinander sprechen (also teamübergreifend).
Die kommt nicht von den Studenten, sondern von den ASTAs. *duckundweg*Auch die ständige Diskutiererei ohne Ergebnis ist etwas was von den Studenten kommt.
Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
Daniel
Seit wann besteht der nicht mehr aus Studenten?DeathAndPain hat geschrieben:Die kommt nicht von den Studenten, sondern von den ASTAs. *duckundweg*Auch die ständige Diskutiererei ohne Ergebnis ist etwas was von den Studenten kommt.
Na ja, es ist die Frage, ob man die linksextremen, der Autonomen Szene zuzurechnenden Berufsstudenten als repräsentativ für die Studentenschaft ansieht oder nicht. Ich tendiere eher zu der Meinung, dass diese Punks mit richtigen Studenten nicht viel zu tun haben. Deswegen werden sie ja regelmäßig nur von 20-30% der Studenten gewählt (oder war es noch weniger? Ist lange her bei mir. Könnte gut sein, dass 20-30% die Wahlbeteiligung war, so dass entsprechend noch viel weniger für die Mehrheit gelangt haben), was aber angesichts der chronisch desolaten Wahlbeteiligung bei den ASTA-Wahlen auszureichen pflegt, um die relative Mehrheit zu erringen. Extreme gehen halt eher zur Wahl als Gemäßigte, und die meisten Studenten wollen was lernen und einen Abschluss machen und interessieren sich nicht für den ASTA. Sicherlich eine Einstellung, die zu kritisieren ist, aber das ist die Sachlage.Seit wann besteht der nicht mehr aus Studenten?Die kommt nicht von den Studenten, sondern von den ASTAs. *duckundweg*