home *** CD-ROM | disk | FTP | other *** search
Autorenrichtlinien für Fachbeiträge in der toolbox Stand: Dezember 1993 _____________________________________________________________________ Der Autor und die Redaktion haben ein gemeinsames Interesse: nämlich dem Leser einen interessanten Beitrag zu präsentieren. Unser gemeinsamer Kunde soll Ihren Beitrag, den Sie sicher mit viel Mühe geschrieben haben, gebührend würdigen können. Aus diesem Grund haben wir einige Leitlinien zusammengefaßt, die ihnen und uns die Arbeit erleichtern können. Die toolbox ist eine Fachzeitschrift für den anspruchsvollen Programmierer. Das Redaktionsteam ist klein und hat nicht die Zeit, arbeitsintensive Beiträge mit dem »gebührenden« Aufwand zu betreuen. Da den Redakteuren die Zeit für die umfangreiche Überarbeitung der Beiträge fehlt, werden solche Artikel zur Überarbeitung an den oder die jeweiligen Autoren zurückgesandt. Dies können Sie dadurch vermeiden, daß Sie die Beiträge entsprechend aufbereitet einsenden. _____________________________________________________________________ Ein Beitrag in der toolbox sollte grundsätzlich folgende Elemente enthalten: o den oder die vollen Namen des oder der Autoren (keine abgekürzten Vornamen) o eine aussagekräftige Überschrift o einen kurzen, den Inhalt betreffenden Einleitungstext, nicht mehr als fünf Zeilen umfassend o den Artikel an sich o die Disketten-Listings-Box o und selbstverständlich: kurze, erläuternde Listing(s)! und bei Bedarf: o Bezugsquellen mit Preis etc. bei allen Reviews o Bildmaterial, zu jedem Bild auch eine Bildunterschrift o Textboxen o vollständige (!) Literaturangaben Je besser die Gliederung und der Aufbau des Beitrags ist, desto weniger Mühe muß die Redaktion in den Beitrag investieren. Dies wirkt sich auch auf die Höhe des Honorars und selbstverständlich auf die Wartezeit bis zur Veröffentlichung aus. Im Einzelnen: 1. Einleitung: Ein selbständiger Einleitungsteil ist wichtig. Inhaltliche Linie: »Vom Allgemeinen zum Speziellen«. Soweit es das Thema des Beitrags zuläßt, sollten die ersten fünf Sätze des Artikels auch vom Nichtfachmann verstanden und nachvollzogen werden können. In der Regel entscheidet der Leser nach dem »Überfliegen« der Einleitung, ob er den gesamten Beitrag liest. Nicht allgemeinverständliche Begriffe und Abkürzungen können bereits hier erklärt werden. Es bieten sich für Erläuterungen aber auch gesonderte Textboxen (Glossare, Informationskästen) an. »Historische« Einleitungen bieten sich ebenfalls an. Bei stark listingbezogenen Beiträgen: Vorgänger und ähnliche Programme. Bei thematischen Beiträgen: Modetrends oder sich wandelnder Bedarf. Weder die Überschrift noch Untertitel von Beiträgen können verbindlich vorgegeben werden. Wir sind aber immer dankbar für entsprechende Vorschläge. 2. Einstieg: Ein klares Auf-den-Punkt-bringen des Beitrags empfiehlt sich direkt nach dem Einleitungsteil. Hier sollten die Programmiersprache, unter Umständen die Compiler- oder Interpreterversion, die Art des Programms und weitere grundlegende Informationen erwähnt werden. Auch Fragen wie beispielsweise der Anwenderkreis oder benötigtes Grundwissen sollten an dieser Stelle abgehandelt werden. 3. Alleinstellung: Der Sinn und Zweck des Beitrags: das »Alleinstellungsmerkmal«. Was ist das Besondere an dem Programm? Warum soll sich der Leser für den thematischen Beitrag besonders interessieren? 4. Zielgruppengerechte Tips: Unsere Leser sind nicht nur »Hardcore«-Programmierer und »Bitbeißer«. Jeder hat schließlich mal klein angefangen! Einsteiger- und Anfängerbeiträge sollten aber auch entsprechend aufgebaut sein und nicht zuviel voraussetzen. Aber trotzdem ist die toolbox ein Programmierer- und kein Anwendermagazin. Bei Programmbeschreibungen steht somit nicht die Programmbedienung, sondern die immer die Codierung im Vordergrund; also: Welche Programmierprobleme wurden bei der Entwicklung gelöst? In welcher Richtung müßte man weiterdenken, um das Programm zu erweitern? Es genügt, wenn bei einem Programm die Bedienung kurz erklärt wird. Die Schilderung von Menüoptionen und Tastenfunktionen sollte, falls überhaupt notwendig (siehe Windows und Turbo Vision), nur ganz kurz sein. In beschreibenden Beiträgen haben Bedienungsanleitungen absolut nichts zu suchen - es sei denn, man kann an einem Beispiel zeigen, wie es nicht gemacht werden sollte! 5. Bilder: Ein Zeitschriftenartikel lebt nicht vom Text allein. Für Bildschirm- und andere Fotos bitten wir um Hinweise und Vermerke. Zu jedem Bild muß (!) auch eine Bildunterschrift vorhanden sein. Hardcopies erleichtern uns die Arbeit. Aber: Kein Redakteur hat die Zeit, eine grobe Bleistiftskizze ins Reine zu übertragen. Hier ist der Autor gefordert. Außerdem: Ein Programmpaket nur für einen Screenshot zu installieren, bedeutet enormen Aufwand. Screenshots macht deshalb besser der Autor selbst. Er weiß am besten, welcher Bildschirm eines Programms sich eignet. Für die Übermittlung der Screenshots gibt es Programme genug: Sowohl das »Snapshot« der toolbox (*.PCX für Grafikbildschirme und *.ATT für Textbildschirme) als auch das Snapshotprogramm der DOS (Exe-Programme) eignen sich hierfür vorzüglich. Die Programme können bei Bedarf jedem Autoren zur Verfügung gestellt werden. Für Windows-Screenshots bieten sich PCX-, BMP- oder das Clipboard-Format an. Zu einem Bild gehört eine Bildunterschrift. Diese sollte aber nicht in einen eigenständigen Artikel ausarten: Bildunterschriften sollten drei Zeilen mit 40 Anschlägen keinesfalls überschreiten. 6. Beispiele: Wo irgend möglich: Beispiele! Aber: Beispiellistings und Bildschirmfotos dürfen nicht fest plaziert werden, etwa nach dem Motto: »... sehen Sie an folgendem Beispiel:«. Lieber dem Kind einen Namen geben: »Das Listingbeispiel >XYZ< macht das deutlich.« Das Beispiel selbst erhält dann die passende Bildunterschrift, etwa so: »XYZ: Wie man sieht, ...«. Allerdings gilt dies nur für längere Listing. Diese werden an den Text angehängt und müssen dann, genauso wie ein Bild eine Listingunterschrift erhalten. Kurze Listingauszüge im Text dagegen dürfen keine Unterschrift bekommen. Sie sind mit Tabulatoren sinnvoll einzurücken. Tabellen und Listings sollten als gesonderter Text, am besten als eigene Datei, abgeliefert werden. Sie werden selbstverständlich entsprechend mithonoriert! 7. Programmlistings, egal in welcher Programmiersprache, müssen grundsätzlich so formatiert werden, daß die Zeilenlänge 60 Zeichen nicht überschreitet. Da in der toolbox Listings nicht numeriert werden, gilt das auch für Sprachen wie beispielsweise COMAL, die Zeilennummern verlangen. Eine Ausnahme bilden Listings, die nicht abgedruckt werden, also nur auf die Diskette kommen. Hier kann unter Umständen ein Umbruch auf maximal 79 Zeichen je Zeile vorgenommen werden. Rücken Sie außerdem die Listings nach toolbox-Manier ein: Blöcke werden um zwei Zeichen eingerückt. Verwenden Sie hierbei keine Tabulatoren. Ein Block-BEGIN in Pascal gehört außer bei Prozedur-/Funktions- und Programmanfängen zur vorherigen Zeile, also: PROCEDURE Demo; BEGIN WHILE x DO BEGIN .... anstelle von PROCEDURE Demo; BEGIN WHILE x DO BEGIN .... Auch Assembler-Programmierer sollten berücksichtigen, daß Einrückungen die Lesbarkeit erhöhen. Außerdem liest sich - insbesondere in C und Assembler - ein sinnvoll kommentiertes Listing besser als eine Codewüste. Rücken Sie auch in C und Assembler sinnvoll ein. Ein MODEL TINY .CODE ORG 100h Start: PUSH AX PUSH BX .... liest sich lange nicht so gut wie die strukturierte Version: MODEL TINY ; Tiny-Model, kein Stack-Segment .CODE ; Code-Segment ORG 100h ; COM-Programm (TLINK /t) Start: PUSH AX ; Register sichern PUSH BX ... Auch Quick-Basic-Programme können umgebrochen werden. Ein Unterstrich (»_«) am Zeilenende führt dazu, daß der Compiler beim nächsten Laden der Quelldatei diese und die nächste Zeile wieder zusammenfügt: SUB DoSomething (s AS STRING, i AS INTEGER, _ m AS UserDefined1, _ n AS UserDefined2) Hack-and-Run-Programme haben in der toolbox nichts zu suchen: Die meisten Leser kaufen eine Fachzeitschrift, um sich weiterzubilden. Der Autor eines in der toolbox abgedruckten Programms sollte dem Anfänger zeigen, daß man sich vor dem Codieren eines Programms auch Gedanken machen sollte, was programmiert wird. Unverständliche Strukturen, nicht nachvollziehbare Sprünge, kryptische Variablen und Sprachkauderwelsch müssen nicht sein! Es geht auch anders. Vermeiden Sie »gemischtsprachige« Variablenausdrücke wie »WriteToSpeicher«. Allgemein gilt für Listings, egal ob sie abgedruckt werden oder auf die Diskette kommen: Strukturierung, Wiederverwendbarkeit und Modularität sind ein unbedingtes Muß. Trennen Sie größere Programme in kleinere Module auf. Setzen Sie bei Turbo Pascal Units, bei C/C++ Projektdateien und Headerfiles und bei Assembler Object-Module ein. Dokumentieren Sie die Listings. Vergeben Sie sprechende Namen für Funktionen/Prozeduren, Variablen, Konstanten und Module. Eine Quelltextdatei sollte in keinem Fall 64 KByte überschreiten! 8. Quellenhinweise: Werden Produkte genannt, muß die Bezugsquelle angegeben sein. Hierzu gehören: Der (möglichst) deutsche Händler oder Hersteller samt seiner Adresse, der Lieferumfang (Disketten, Handbücher etc.), der Preis (inklusive MwSt.) und bei Büchern die ISBN-Nummer. Diese Informationen sollten als gesonderter Hinweistext für die Redaktion gekennzeichnet sein und werden in gesonderte Kästen gestellt. Ein Buch sollte beispielsweise so zitiert werden: Michael Starke (Hrsg.): Borland Pascal 7.0 -- Das Buch. te-wi Verlag, München, 1993, ISBN 3-89362-288-8, 1103 Seiten, 2 Disketten, DM 89. Ein Zeitschriftenartikel wird dagegen so (und nicht anders) zitiert: Wolfhard Rinke: Easy-Vision, DOS toolbox 3'93, S. 8-11, DMV-Verlag, 1993. Querverweise auf andere Publikationen des Verlags sind erwünscht. Wir haben aber auch keinerlei Berührungsängste, wenn jemand Blätter anderer Verlage erwähnt. Uns ist es lieber, sie zitieren die Quellen. Es ist erheblich schlechter, wenn später der Vorwurf des »Abkupferns« gestellt wird. Wie Sie die Querverweise auf die Literatur im Text vornehmen, bleibt Ihnen überlassen. Allerdings sollten Sie die Indizierung so vornehmen, daß der Text dabei lesbar bleibt. 9. Erläuterungen: Kurze Exkurse zum allgemeinen Verständnis sollten verstärkt eingesetzt werden: Ein selbstprogrammierter Gerätetreiber sollte nicht ohne Grundlagen der Treiberprogrammierung, ein Beitrag über eine exotische Sprache deren Herleitung und Geschichte enthalten. Solche Exkurse können als selbständige Textkästen gekennzeichnet sein und müssen in jedem Fall für sich verständlich sein. Werden sie in den Fließtext des Artikels eingebunden, müssen sie unbedingt wieder zum Ausgangspunkt zurückkehren. 10. Glossare, Abkürzungs- und Fachwort-Erklärungen zum Text sollten intensiv verwendet werden. Sie ermöglichen das Lesen der Texte auch Einsteigern, ohne »Alte Hasen« durch weitschweifige Erläuterungen im Fließtext zu langweilen. 11. Wer Literatur verwendet, bricht sich keinen Zacken aus der Krone, wenn er dies zugibt. Aber: Es hilft niemandem, wenn dann das Literaturzitat nicht angegeben ist oder so unvollständig angeben wird, daß man das entsprechende Buch oder den entsprechenden Zeitschriftenartikel nicht findet. Eine Literaturliste mit vollständig angegebenen Daten wirkt hier Wunder. Auch eine kurze Wertung der verwendeten Literatur ist an dieser Stelle angebracht. Für wen ist das Werk geeignet? Wie ist der Schreibstil des Autoren? Diese Punkte und auch die Frage, ob ein Buch weiterempfohlen werden kann, sind Fragen, die Sie dem Leser beantworten müssen. Leitfragen Es lohnt, sich beim Schreiben die folgenden Leitfragen zu stellen: 1. Welches Kenntnis-Detail könnte einem Leser das Gefühl geben, er wisse nach dem Lesen meines Beitrags mehr als die Leser anderer Zeitschriften? Und vor allem: mehr als vor dem Lesen des Artikels! 2. Fachbeiträge müssen nicht staubtrocken sein: Hatte der Leser wenigstens einmal die Gelegenheit zu Schmunzeln? Trat ein Aha-Erlebnis auf? Würde man den Artikel selber lesen? 3. Was kann ich tun, um bestehende Bedürfnisse aufzunehmen? Könnte ich mir einen Leser vorstellen, für den mein Beitrag Grund genug zum Kauf der toolbox ist? Stilistisches 1. Allgemein: Die allgemeine Zielrichtung von toolbox-Beiträgen läßt sich mit folgendem Stichwort beschreiben: »Fachinformation, möglichst verständlich und unterhaltsam vermittelt«. Aber übertreiben Sie die »Unterhaltsamkeit« nicht! Zu den Lesern der toolbox gehören »Anfänger« ebenso wie »Fachleute« aller Altersgruppen. 2. Fakten und Meinungen: Überall wo Sie Ihre eigene Meinung sagen, muß dies für den Leser klar ersichtlich sein. Grundlagen-Informationen, neutrale Beschreibungen und persönliche Wertung dürfen nicht vermischt werden. Die beste Möglichkeit ist, dem Leser die Information zu geben. Die Wertung kann er selbst treffen. Das Arbeiten mit Funktionen, Methoden und Hilfsmitteln sollten Sie aus eigener Anschauung mitteilen; hier ist lockerer Stil nicht nur gewünscht sondern sogar geboten. Was den Humor angeht: Anekdoten und humorvolle Übertreibungen sind erwünscht. Es muß aber darauf geachtet werden, daß sie sparsam eingesetzt werden. Übertriebene »Flapsigkeit« ist schädlich. Es sollte zur Zeitung passen, also nicht auf das Niveau einer »Schülerzeitschrift« absinken. Humor darf keineswegs selbstgerecht oder womöglich gar überheblich sein oder wirken. Manchem Leser stößt »Flapsigkeit« unangenehm auf. Allein schon dadurch, daß unter übertrieben humoristischem Stil allzugern die zu übermittelnde Fachinformation leidet. Die toolbox ist eine Fachzeitschrift und kein Magazin! 3. Recherche: Die Redaktion übernimmt mit dem Abdruck eines Beitrags die Verantwortung für dessen Form und Inhalt. Private »Abrechnungen« sind im Text unbedingt zu unterlassen. Weder Privatpersonen noch Firmen oder Institutionen dürfen undifferenziert angegriffen werden. Dies soll kein Hindernis für sachliche Kritik sein, wenn sie zum Thema des Beitrags gehört! Ein Beispiel kann dies gut verdeutlichen: Der Begleittext zu einem Artikel über DFÜ darf den Hinweis enthalten, daß in Deutschland noch immer recht restriktive Postbestimmungen herrschen. Daß die Regelungen in anderen europäischen Ländern oder in den USA dem Autoren besser behagen und er die Haltung der Bundespost-Telekom bedauert, kann deutlich ausgedrückt werden. Aber: Ein allgemeiner Rundumschlag nach dem Motto »... der verkrustete und verbeamtete Gilb - und überhaupt sind die Gebühren eine Unverschämtheit ...« gehört nicht in die Zeitung. Die toolbox ist kein Underground-Medium. Sie ist vielmehr gehalten, die »guten Sitten« auch im Umgang mit Bevölkerungsgruppen oder religiösen Vereinigungen zu wahren. 4. Der Passiv: Passive Wendungen machen einen Text langweilig, wenn sie gehäuft auftreten. Statt »Bei der Benutzung der Hilfsprozedur werden Variablen initialisiert« kann man erheblich besser schreiben: »Die Hilfsprozedur initialisiert Variablen«. Auch wenn man mit bildhaften Wendungen und Vergleichen arbeitet, kann man damit trockenen Stil und dauernde Passiv-Konstruktionen vermeiden. Eine Konstruktion wie »Die Hilfsprozedur zeigt den Variablen, wo es langgeht.« ist aber schon wieder hart an der Grenze. 5. Bandwurmsätze: Möglichst kurze Sätze formulieren! Bei drei Kommas ist die »Schmerzgrenze« meist schon erreicht. Als Zeiten sollten Sie bevorzugt Präsens und Perfekt verwenden. 6. »Wir« und »uns« sollten nur benutzt werden, wenn mit »wir« die toolbox-Redaktion gemeint ist. Schulmeisterhaftes »Betrachten wir nun Beispiel 3. Was fällt uns daran auf?« ist häßlich und wird ungern gelesen. Wo es sich irgend geht: Vermeiden Sie diesen für den Leser unangenehmen »Oberlehrer-Stil«. Vermeiden Sie außerdem einen durchgehenden »Ich«-Stil. Unterlassen Sie auch die »Anbiederung« beim Leser. Verzichten Sie, sofern möglich, auf die häufige direkte Ansprache mit »Sie«. Wir machen keine Bücher sondern Zeitschriften! 7. Selbständigkeit: Der Text des Beitrags sollte selbständig sein, also nicht von irgendwelchen Zusatzelementen abhängen. Ein logischer Faden muß diesen selbständigen Text durchziehen. Zwischenüberschriften sind layouterische Hilfsmittel, keine textlichen. Vorschläge für Zwischenüberschriften sind zwar willkommen. Zwischenüberschriften müssen aber genausogut auch wegfallen können, ohne daß ein Bruch im Text entsteht! 8. Listen und Aufzählungen: Aufzählungen sind ein leidiges Thema: Man kann sie zwar nicht immer vermeiden, sie wirken aber ermüdend. Statt langer Aufzählungen im Fließtext sollten lieber eigenständige Tabellen eingeplant werden. Diese sorgen für Übersicht und lockern die »Bleiwüste« auf. Sie sind als gesonderte Textkästen zu kennzeichnen. Gute Beispiele dafür: Befehlslisten, Variablenlisten, Funktionslisten. 9. Kommunikation zwischen Autor und Redaktion ist unerläßlich. Aber wie sollen Sie die Beiträge überhaupt abliefern? Ganz einfach: Den Text auf einer Diskette (ein Ausdruck reicht uns nicht!). Textboxen und Tabellen sollten vom Text getrennt in eigenen Dateien sein. Alle Texte und Listings benötigen wir zusätzlich auch als Ausdruck. Die Bilder benötigen wir ebenfalls auf Diskette (*.PCX, *.BMP oder *.EXE-Files). Zu einer Compilerbesprechung gehört auch ein Beispielprogramm. Dieses sollte - wenn möglich - einen gewissen »Nährwert« besitzen und gerade bei Exoten die Struktur der Sprache zeigen. Und gerade bei Compilern: Kopieren Sie auch das erzeugte Com- oder Exe-File mit auf die Diskette. Zusammen mit dem ordentlich umgebrochenen Quellcode! Falls bei einer Compilerreview Benchmarks gemacht wurden, sollte der Quellcode der Benchmarks selbstverständlich auch auf der Diskette sein. Alle Texte auf der Diskette müssen im ASCII-Format ohne Steuerzeichen vorliegen. Also nicht in irgendeinem Textverarbeitungsformat, sei es nun XYWrite oder Word für Windows. Und Postscript-Files wollen wir auch nicht. Die Texte müssen unformatiert sein - also kein Block- sondern Flattersatz - und dürfen keine Worttrennungen enthalten (also: automatische Trennung abschalten!). Bilder: Das bedeutet nicht nur Screenshots. Erläuternde Grafiken in Form von Bleistiftskizzen oder Ausdrucken von Nadeldruckern sind nicht brauchbar. Wir benötigen grundsätzlich reprofähige Vorlagen! Dies müssen sauber gezeichnete Tuschevorlagen sein - die sollten aber so an uns gesandt werden, daß die Post nichts kaputt machen kann. Als Alternative zur Tuschezeichnung bieten sich vektororientierte Grafikprogramme an; auf keinen Fall Pixelmalprogramme . Geeignete Programm sind: AutoCad/AutoSketch, GEM Artline, Micrografx-Designer, Corel Draw oder ähnliches. Falls es sich um ein weitverbreitetes Programm bzw. Grafikformat handelt, können die Grafiken im jeweiligen Format übergeben werden. Als brauchbare Alternative bieten sich - im Gegensatz zu Texten - aber auch das Postscript- oder HPGL-Format an. Hardcopies vom Nadeldrucker können wir nicht verwenden. Kopieren Sie die Hardcopy in eine Datei. Benutzen Sie dabei einen HP-Laserjet oder Postscript-Druckertreiber oder ein Snapshot-Programm. Unter Windows: Installieren Sie einen Drucker mit Ausgabeziel »Datei«. Und so nicht! In einem Beitrag für die toolbox haben einige Sachen absolut nichts zu suchen: 1. Regieanweisungen wie »im folgenden soll es um ... gehen« oder »nachdem im ersten Absatz die grundsätzlichen Fragen zu klären sind, ...« bitten wir unbedingt zu vermeiden. Wenn der Artikel gut aufgebaut ist, merkt der Leser auch ohne solche Überleitungen, wie er aufgebaut ist. Wenn ein »Vorblick« gewünscht wird, kann man ihn im Einleitungstext unterbringen, sollte ihn dann aber möglichst locker formulieren. Ein Beispiel, wie es besser klingt: »Wenn Sie wissen möchten, welche Feldtypen man besser nicht benutzt, sollten Sie jetzt weiterlesen ...« 2. Problemgeschichten wie »Aus Zeitmangel konnte das Beispiellisting nicht wasserdicht gemacht werden« oder die Schilderung innerer Dramen wie »ich überlegte hin und her, was nun das Thema dieser Folge unseres Kurses sein sollte ...« finden kein bis wenig Verständnis bei unseren Lesern - und in der Regel auch kein Verständnis in der Redaktion! 3. Kapitel und Unterkapitel (Beispiel: »1.2 Handhabung; 1.2.1 Der Editor«) sowie andere akademische Gepflogenheiten haben keinen Platz in toolbox-Beiträgen. Merke: Ein Zeitschriftenartikel ist keine Seminar- oder Diplomarbeit! 4. Aufzählungen von mehr als vier Zeilen Länge sind ebenso leserfeindlich wie Sätze mit mehreren »und«. Unbeholfen klingt es, wenn Formen von »können« in mehreren aufeinanderfolgenden Sätzen benutzt werden. Beispiel: »Mit dem Utility kann man den Speicher bequem durchforsten. Man kann Strings suchen, Hexzahlen wandeln und Daten ändern; auch eine 'Memory-Map' kann man abrufen«. Das Wort »kann« sollte außerdem, soweit möglich, vermieden werden. Oft wird dieser (leicht universitäre) Stil nur benutzt, um Unsicherheiten zu überspielen. Unsere Regel: Wenn man es machen kann, dann machen wir's (und lassen das »kann« einfach weg). Das obige Beispiel sähe dann so aus: »Mit dem Utility durchforstet man bequem den Speicher;.Strings zu finden, ist einfach, das Wandeln von Hexzahl und die Änderung von Daten werden erleichert. Ein weiteres Feature des Programms ist die Memory Map, ...«. 5. Längungen: Wie jede andere Zeitschrift hat auch die toolbox ihre Platzprobleme. Erschweren Sie uns die Arbeit bitte nicht dadurch, daß sie wenig aussagekräftige Passagen als Längung einfügen, um vielleicht auf »vereinbarte 10 Seiten« zu kommen. Sie haben die Arbeit mit dem Schreiben, wir mit dem Löschen! Lieber ein gestraffter kürzerer Text als ein gestreckter. Je pünktlicher Sie Ihr Werk abliefern, desto weniger Probleme hat die Redaktion mit dem Längenausgleich durch andere Beiträge. 6. Verbotene Worte: In der deutschen Sprache gibt es einige »böse Worte«. Entweder klingen sie zweideutig oder nur einfach schlecht. Diese Worte können normalerweise problemlos ersetzt werden. Tun sie das. Vor allem: o beinhalten o existieren o erstellen o befinden o Möglichkeit o machen o gehören sind in allen Formen (so weit es geht) zu vermeiden! 7. Hauptwörter und Verben: Vermeiden Sie »Beamtendeutsch«. Entsprechende Verben sind immer besser als Hauptworte auf »ung«. 8. Welcher, welche, welches ... Ein unschöner, wenn auch grammatikalisch korrekter Ersatz für »der«, »die« und »das« nach Kommas, sind die Worte »welcher«, »welche« und »welches«. Man findet diese Worte nicht nur in (schlechten) Übersetzungen, sondern auch in deutschen Originaltexten immer wieder. Ein Satz mit »Der Text, welchen ich ....« klingt übel. Verzichten Sie grundsätzlich darauf. Verwenden Sie besser die Artikel der, die und das in den jeweilgen Deklinationsformen: »Der Text, den ich ...« liest sich erheblich angenehmer. Schreibvereinbarungen Es gelten im wesentlichen die Schreibvereinbarungen der DOS-International, die wir Ihnen auf Wunsch gern zusenden. Hier soll nur das wichtigste angerissen werden: 1. Bindestriche: In der Regel werden zusammengesetzte Hauptwörter im Deutschen ohne Bindestriche, also zusammengeschrieben. Ausnahmen: o Wenn Mißverständnisse entstehen können oder das Wort schwer lesbar wird. o Wenn Fremdwörter und deutsche Wörter zu einem Wort zusammengesetzt werden und das fremdsprachliche Wort noch nicht hinreichend eingebürgert ist. Zum Beispiel: Cache-Speicher, Escape-Sequenzen. o Wenn Eigennamen Teil des zusammengesetzten Wortes sind, wie IBM-Betriebssystem. Als Eigennamen zählen dabei auch Programmiersprachen (Assembler-Routine, Pascal-Programm). 2. Zahlen: o Zahlen bis Zwölf werden im Fließtext ausgeschrieben. o Bei Mengenangaben und Meßwerten werden immer Ziffern verwendet: 10 KByte. o Maßeinheiten werden ausgeschrieben, mit Ausnahme von KByte, KBit, MHz, cm etc. o Das »K« in KByte bedeutet nicht »Kilo« sondern steht für 1024. 1 GByte = 1024MByte, 1 MByte = 1024 KByte, 1 KByte = 1024 Byte. o Dezimalstellen werden im Deutschen immer durch ein Komma, nicht durch einen Punkt getrennt. o Eine Trennung von Tausenderstellen gibt es nicht. Zum Beispiel: 100000. 3. Anführungszeichen: Es werden grundsätzlich die französischen Anführungszeichen » und « verwendet (ASCII 175 (») und 174 («). Sowohl einfache (') als auch doppelte Anführungszeichen (") müssen von der Redaktion geändert werden und bedeuten einen (unnötigen) zusätzlichen Mehraufwand. Benutzen Sie das Programm »f11f12.com« aus der DOS toolbox 3'93 für Ihre DOS-Textverarbeitung. Es legt die französischen Anführungszeichen auf die sonst ungenutzten Funktionstasten [F11] und [F12]. »f11f12.com« ist mit allen DOS-Textverarbeitungen (auch von Microsoft) verträglich. 4. Apostroph: Ein Genitiv oder Plural-s mit Apostroph abzutrennen, ist im Deutschen nicht zulässig. Die Mehrzahl- und Genitivbildung von Abkürzungen wie PC oder AT erfolgt genauso: ATs, PCs. 5. Umlaute: Es gilt die deutsche, nicht die schweizerische Rechtsschreibung. Falls ein »ß« in das Wort gehört, hat an dieser Stelle ein »ss« nichts verloren. Konstruktionen mit ae (Ae), oe (Oe) und ue (Ue) anstelle von ä (Ä), ö (Ö) und ü (Ü) sind ebenfalls unerwünscht und erhöhen den Arbeitsaufwand des Redakteurs unnötig. 6. K und c: Einige EDV-Fachbegriffe werden langsam aber sicher eingedeutscht. Trotzdem: Schreiben Sie Compiler (nicht Kompiler) und compilieren anstelle von kompilieren. Auch das »Kompilat« sieht als Compilat erheblich besser aus. 7. Dateinamen: Dateinamen werden in Anlehnung an die Schreibvereinbarungen der DOS-International klein und in Anführungszeichen geschrieben. Beispiel: »autoexec.bat«. Aber in zusammengesetzten Wörtern wird die Autoexec.bat-Datei groß geschrieben. 8. Gedankenstriche: Die Satzanlage kann den Unterschied zwischen »-« (Bindestrich) und »-« (Gedankenstrich) nicht erkennen. Sie erleichtern uns die Arbeit, wenn Sie von vornherein Gedankenstriche mit zwei aufeinanderfolgenden Bindestrichen schreiben: »--«. 9. Tastatursymbole Sie gehören in eckige Klammern: »[F11] löst ...« zeigt deutlich, was gemeint ist: Eine Taste auf der Tastatur und nicht irgendeine Variable. »Durch das Drücken der [F1]-Taste ...« ist aber in sich redundant. Schreiben Sie dann lieber: »Durch den Druck auf [F1] ...«. 10. englische Ausdrücke Schreiben Sie »Tastatur« anstelle von »Keyboard« und »Diskettenlaufwerk« statt des »Floppy-Laufwerks«. Aber übertreiben Sie die Eindeutschungen nicht. Der »Übersetzer« sollte ein »Compiler« bleiben. Auch wenn sich die Geister scheiden, ob »Netzwerk« ein sinnvoller deutscher Begriff ist, lassen Sie es dabei. Verwenden Sie die Fachausdrücke - auch wenn der eine oder andere Germanist Zweifel am Sinn des Wortes hat. 11. Ph und F Schreiben Sie »Foto«, »Grafik« und »Telefon« mit »f«, auch wenn Sie Leser der Süddeutschen Zeitung sind. »Fotograf(ie)«, »Grafiker« und »Telefonistin« tun auch nicht weh. Lassen Sie das »ph« den Worten, die noch nicht eingedeutscht sind, wie beispielsweise dem Philosophen und den Philologen. 12. Abkürzungen Abkürzungen wie »bspw.«, »z.B.«, »i.A.«, »u.a.«, »etc.«, »usw.« sind nicht zulässig. Ersetzen Sie Abkürzungen durch das oder die ausgeschriebenen Worte. Wenn Sie Ihnen selbst dann seltsam vorkommen, ersetzen Sie sie oder stellen Sie den Satz so um, daß »zum Beispiel« überflüssig wird. 13. Füllworte Gern und oft benutzt werden Füller nach Kommas, lassen Sie diese Worte (in Regel sind es »so«, »nun« , »also« und »dann«) einfach weg. Sie sind überflüssig und werden vom bearbeitenden Redakteur sowieso entfernt: Aus: »Wenn Sie nun etwas soundso machen, so können Sie sehen ...« oder: »Wenn Sie nun etwas soundso machen, dann können Sie also sehen ...« wird dann: »Wenn man etwas soundso macht, sieht man ...« 14. Listing-Header Zu jedem Listing gehört ein Listing-Header. In diesen gehören der Name des Programms, der Name des Autoren und die Compiler-Version für die das Programm geschrieben wurde und sonst nichts. Auch hier muß ein gewisser Formalismus gewahrt bleiben. In Pascal (und auch in Modula) sollte so ein Header folgendermaßen aussehen: (* ======================================================= *) (* DEMO.PAS *) (* (C) 1993 Fritz Hackermann & toolbox *) (* Compiler: Borland Pascal Version 8.0 *) (* Zielsystem: Windows NT 1.0 *) (* ======================================================= *) Fügen Sie bei Turbo und Borland Pascal die verwendeten Compilerschalter in das Programmlistung ein. Sehr einfach geht das mit der Tastenkombinaten [Ctrl][O]-[O] im Pascal-Editor. Sie ersparen der Redaktion und den Lesern manches Grübeln, warum ein Programm vielleicht nicht ordnungsgemäß compiliert wird oder warum im Gegensatz zu dem vom Autoren mitgelieferten Compilat das Compilat aus der Redaktion aussteigt. Verwenden Sie anstelle der geschweiften Klammern ({}) für Kommentare besser die Alternativmethode mit »(*« und »*)«. Bei abgedruckten Listings geht die geschweifte Klammer gern in der Druckerei verloren. Bei C-/C++-Programmen sollte ein Header ähnlich aussehen: /* ======================================================= */ /* DEMO.CPP */ /* (C) 1993 Fritz Hackermann & toolbox */ /* Compiler: Borland C++ 4.0 */ /* Speichermodell: Huge */ /* ======================================================= */ Schreiben Sie - falls das Programm nur in bestimmten Speichermodellen compilierbar ist, dieses Speichermodell in den Header. Dokumentieren Sie Pragmas im Listing, falls sie benötigt werden, nicht nur in der IDE. Bei Basic muß ein Listing-Header wiederum so aussehen: '* ======================================================== * '* DEMO.BAS * '* (C) 1993 Fritz Hackermann & toolbox * '* Compiler: Quick-Basic 4.5 * '* QB.BI muß eingebunden sein! * '* ======================================================== * Bei Assemblerlistings sollte der Header in diesem Stil aufgebaut sein: ;* ======================================================== * ;* DEMO.ASM * ;* (C) 1993 Fritz Hackermann & toolbox * ;* Assembler: TASM ab 2.0 * ;* Speichermodell: Tiny * ;* Übersetzen mit: TASM demo / TLINK demo /t * ;* ======================================================== * Wer sich einen Quelltext in den Editor lädt, weiß dann sofort, was Sache ist und spart sich das lästige und unnötige Herumprobieren, das Leser (und auch Redakteure) verärgert. Verwenden Sie in Copyright-Hinweisen nicht das englische Wort »by«! Anstelle der Gleichheitszeichen dürfen auch Sternchen (»*«) verwendet werden. Benutzen Sie bitte keine Bindestrichlinien in Kommentaren (»-«); das verträgt die Satzanlage nicht! Und es entscheidet letztendlich die Redaktion, welches Listing abgedruckt wird! 15. Die Deutsche Mark In Abweichung von der Richtlinien der DOS International werden Währungen abgekürzt, es wird also »DM« anstelle von »Mark« geschrieben. 16. Satzanweisungen Prinziell braucht sich der Autor nicht um Satzanweisungen kümmern. Es reicht, wenn ASCII-Fließtext abgegeben wird. Falls Sie trotzdem das Bedürfnis haben, Ihre Texte selbst zu gliedern, hier eine Liste der wichtigsten Steuerbefehle. Jedes Steuerzeichen wird mit einem Klammeraffen »@« eingeleitet und durch Doppelpunkte »:« beendet: @a: Autorenname(n) @u: Überschrift @e: Einleitungstext @n: Normaltext (Fließtext) @x: einfache Textbox (Literatur) @xz: Textbox mit Überschrift (Listings) @kz: Überschrift in einer Box @z: Zwischenüberschrift im Fließtext @b: Bild- und Listingunterschrift @f: Fettschrift @k: kursive Schrift Eine Ausnahme bilden tiefgestellte Indizes und hochgestellte Potenzen: <+>hochgestellt<+> <->tiefgestellt<-> Aber übertreiben Sie die Satzanweisungen nicht. Mehr als fünf Schriften gehören nicht auf eine Seite! _____________________________________________________________________ Und denken Sie daran: Diese Richtlinien sind keine Schikane. Sie sollen Ihnen und uns die Arbeit erleichtern. Seitenumfänge toolbox: Zweispaltiger Umbruch: 1. Seite: 80 Zeilen à 48 Zeichen (bei einzeiliger Überschrift und vier Zeilen Einleitungstext), abzüglich Aufmacher. ab der Seite 2: 116 Zeilen à 48 Zeichen (abzügl. Textboxen und Screenshot. Je Bild - 17 Zeilen. Grundsätzlich abzurechnen sind Zwischenüberschriften und Listings im Text. Boxen (Bücherkisten etc.): Bei 1/2-hoch im Zweier-Umbruch etwa 59 Zeilen à 45 Zeichen Listings: 220 Zeilen je Seite, 60 Zeichen breit. Abzuziehen ist die Listingunterschrift (zwei Zeilen) Und ganz zum Schluß: Honorarsätze: Was Sie als Autoren oder Autorin ganz besonders interessieren dürfte, sind unsere Honorarsätze. Diese sind selbstverständlich »qualitätsabhängig«. Das heißt nichts anderes als: »Je weniger Zeit die Redaktion aufwenden muß, desto mehr Geld gibt es für den oder die Autoren«. Es gibt allerdings Höchstgrenzen: Wir bezahlen im Regelfall zwischen 200 und 300 DM die Druckseite für Text. Wer die 300-DM-Grenze erreichen will, muß aber nicht glauben, daß er »druckfertige« Manuskripte abliefern muß. Vielmehr erwarten wir hier guten Stil und ordentliche Orthographie. Zu einem guten Text gehören auch entsprechende Bilder und Grafiken, sofern diese einen Sinn machen. Bei angeforderten Beiträgen bezahlen wir nur die angeforderten Seiten und nicht einen Überhang des Autoren. Wer also statt der angeforderten 5 Seiten 10 Seiten abliefert, bekommt 5 Seiten honoriert! Text und Grafiken wollen wir auf Diskette. Ausdrucke auf Papier honorieren wir nicht (wenn wir sie überhaupt veröffentlichen). Listings honorieren wir ebenfalls nach Qualität. Auch hier gilt: »Je weniger die Redaktion daran machen muß, desto höher bezahlt« -- zwischen 90 DM je Druckseite und maximal 150 DM die Druckseite. Eine »Druckseite bezieht sich auch auf nicht abgedruckte Listings, also solche, die »nur« auf die Diskette kommen. Hier berechnen wir als zu berechnenden Seitenumfang 220 Listingzeilen pro Seite. Bei Listings für die Diskette gibt es aber eine Höchstgrenze. Wir bezahlen pro Beitrag für Listings maximal 3500 DM. »Qualität« bei Listings ist kein subjektiver Begriff. Allerdings müssen Sie verstehen, daß wir in der Regel ein Assemblerlisting weniger hoch bewerten als ein kompaktes C-Listing. Dies liegt in der Natur der Sache. Der C-Programmierer drückt nun einmal 20 Zeilen Assembler in einer Zeile Quellcode aus. Ein Helpfile, in dem dasselbe nochmals steht, wie im Text, honorieren wir genauso wenig, wie wir Überschneidungen von abgedruckten und auf Diskette befindlichen Listings zweimal honorieren. »Cut-And-Paste«-Teile in Programmen werden nicht bezahlt. Wir bitten die Autoren, auch im Sinne der Leser, solche Teile in Programmen, die aus Originalbibliotheken stammen, kenntlich zu machen. Zweitabdruck und Ausfallhonorare: Falls ein (angeforderter) Beitrag einmal nicht abgedruckt werden kann, gibt es das branchenübliche Ausfallhonorar (derzeit 25%). Ausfallhonorare werden nicht bezahlt, solange die Vertragsvereinbarungen nicht erfüllt sind, d.h. Programme oder Text noch mängelbehaftet sind. Für Texte, die nach der Erstveröffentlichung nochmals unverändert abgedruckt werden, bezahlen wir 25% des Erstabdruck-Honorars. Dieses Honorar erhält der Autor ohne weiteren Vertrag. Für verbesserte Listings bezahlen wir die Änderungen, nicht jedoch Originalpassagen. Hierfür wird ein neuer Vertrag -- quasi ein »Bugreport-Vertrag« abgeschlossen. 
