Wiki: Tutorial Grundlagen von Strings und Arrays
Matthias Scharwies
- javascript
- selfhtml-wiki
Servus!
Ich habe mich mal an einem Tutorial versucht:
JavaScript/Tutorials/Grundlagen von Strings und Arrays
Kennt jemand ein praxisnahes Beispiel, in dem man eine Teilzeichenkette mit indexOf sucht? (Suchen aller Vorkommen von 'e' oder 'has' scheint mir zu theoretisch, wenn braucht man sowas konkret?)
Blacklist für Eingabefelder
Sortieren von Namen (Orten) (charcodeAt bringt bei Umlauten falsche Ergebnisse, also localeCompare)
Ich bin für alle Anregungen und Rückmeldungen dankbar.
Herzliche Grüße
Matthias Scharwies
Tach!
Erstmal nur ein Beispiel. Stringmanipulation habe ich ansonsten eher so selten, dass ich mich an nichts erinnere, das großartig über ein Zusammensetzen mit + oder Aufteilen mit split() hinausgeht.
- Kennt jemand ein praxisnahes Beispiel, in dem man eine Teilzeichenkette mit indexOf sucht? (Suchen aller Vorkommen von 'e' oder 'has' scheint mir zu theoretisch, wenn braucht man sowas konkret?)
Für einfache Filterfunktionen verwende ich das mitunter. Gegeben ist eine Datenhaltung, zum Beispiel ein Array mit Objekten, die Datensätze darstellen. Aus diesen wird die Ausgabe in Form eine Tabelle oder Liste erstellt. Der Anwender bekommt ein Eingabefeld, in dem ein Wert angegeben werden kann, der innerhalb des jeweiligen Datenfeldes vorkommen muss. Es gibt keine contains-Funktion in Javascript, so dass hier indexOf() herhalten muss, bei dem mich nur interessiert, ob es größer als -1 liefert, was für nicht enthalten steht.
var searchTerm = 'test'; // kommt eigentlich aus dem Eingabefeld
var filteredRecords = records.filter(function (record) {
return record.name.indexOf(searchTerm) > -1;
});
record ist mein Array of Objects. Die Objekte haben eine Eigenschaft name, nebst anderen in denen hier nicht gesucht werden soll.
dedlfix.
Hallo dedlfix
Es gibt keine contains-Funktion in Javascript, so dass hier indexOf() herhalten muss, bei dem mich nur interessiert, ob es größer als -1 liefert, was für nicht enthalten steht.
var searchTerm = 'test'; // kommt eigentlich aus dem Eingabefeld var filteredRecords = records.filter(function (record) { return record.name.indexOf(searchTerm) > -1; });
record ist mein Array of Objects. Die Objekte haben eine Eigenschaft name, nebst anderen in denen hier nicht gesucht werden soll.
Ich finde, die Prüfung auf Existenz mittels indexOf wie in deinem Beispiel ist nicht wirklich gut lesbar. Wenn wir diesen Aspekt jedoch ignorieren, dann kann man das unter Verwendung des bitweisen NOT-Operators auch etwas kürzer schreiben:
var filteredRecords = records.filter(function (record) {
return ~record.name.indexOf(searchTerm);
});
Tatsächlich gibt es aber mittlerweile eine Methode deren eigentlicher Zweck es ist zu prüfen, ob eine Zeichenkette in einer anderen Zeichenkette enthalten ist, nämlich String.prototype.includes:
const filteredRecords = records.filter(record => record.name.includes(searchTerm));
Das ist deutlich besser lesbar, denke ich.
Wenn es das Ziel ist, die Indexposition eines Teilstrings zu ermitteln, dann kann indexOf oder lastIndexOf verwendet werden. Geht es aber darum zu prüfen, ob ein Teilstring in einem anderen String enthalten ist, dann ist includes das Mittel der Wahl.
Die Methode includes wird allerdings noch nicht von allen relevanten Browsern unterstützt, weshalb vorerst ein Polyfill bereitgestellt werden sollte. Ein solches ist jedoch schnell geschrieben und noch schneller kopiert und eingefügt.
String.prototype.includes besitzt darüber hinaus auch Schwestermethoden. Eine gleichnamige Methode ist zum Beispiel auch für Arrays definiert:
const numbers = [1, 2, 3, 4, 5];
console.log(numbers.includes(3), numbers.includes(7)); // true false
Zu der Methode Array.prototype.includes habe ich vor einiger Zeit einen recht umfangreichen Artikel im Wiki geschrieben, der auch ein Polyfill enthält. Der Rückgriff auf indexOf in solchen Fällen ist also auch bei Arrays nicht mehr nötig.
const typedArray = new Uint8Array([1, 2, 3, 4, 5]);
console.log(typedArray.includes(5)); // true
Gleiches gilt für TypedArrays, die ebenfalls eine includes-Methode besitzen.
Gruß,
Orlok
Tach!
Ich finde, die Prüfung auf Existenz mittels indexOf wie in deinem Beispiel ist nicht wirklich gut lesbar.
Es ist nicht semantisch. Aber was willste machen, wenn kein semantisches Konstrukt (ausreichend verbreitet) verfügbar ist? Die Nicht-Semantik in einer String-Erweiterung verstecken, die dann einen die Bedeutung besser rüberbringenden Namen hat? Für einen einzelnen Funktionsaufruf? (Die richtige Antwort auf diese rhetorische Frage ist includes und Polyfill.)
Wenn wir diesen Aspekt jedoch ignorieren, dann kann man das unter Verwendung des bitweisen NOT-Operators auch etwas kürzer schreiben:
var filteredRecords = records.filter(function (record) { return ~record.name.indexOf(searchTerm); });
Das finde ich noch weniger lesbar. Es nähert sich durch die Bit-Operation statt einer logischen, dessen Ergebnis dann implizit wieder in Logik umgewandelt wird, auch nicht weiter dem semantischen Ziel an. Stattdessen muss man nun auch noch die Zahlendarstellung im Zweierkomplement kennen, um zu wissen, dass bei -1 alle Bits gesetzt sind. Ich musste das eben grad erstmal nachschlagen, um das Arbeitsprinzip zu verstehen. Dass ~
eine bitweise Negation ist, hast du ja schon vorab "verraten". Wer arbeitet denn bei Javascript mit Bits?
Tatsächlich gibt es aber mittlerweile eine Methode deren eigentlicher Zweck es ist zu prüfen, ob eine Zeichenkette in einer anderen Zeichenkette enthalten ist, nämlich String.prototype.includes:
const filteredRecords = records.filter(record => record.name.includes(searchTerm));
Das ist deutlich besser lesbar, denke ich.
Jetzt ja. Damit ist dann auch das Anwendungsbeispiel obsolet geworden.
In der eigentlichen Frage sind wir damit nicht weitergekommen. Mir fallen aber nur Fälle ein, bei denen man damit Probleme lösen kann, die man sich selbst durch Nichtnormalisierung von Daten selbst eingebrockt hat.
Die Methode includes wird allerdings noch nicht von allen relevanten Browsern unterstützt, weshalb vorerst ein Polyfill bereitgestellt werden sollte. Ein solches ist jedoch schnell geschrieben und noch schneller kopiert und eingefügt.
Jein. Man müsste noch den zweiten Parameter berücksichtigen. Und dann kopiere ich mir lieber das Polyfill aus dem MDN statt meine Zeit mit der Zweiterfindung des Rades zu verbringen.
dedlfix.
Tach!
Jetzt ja. Damit ist dann auch das Anwendungsbeispiel obsolet geworden.
Wobei, besser als ein konstruiertes Beispiel finde ich das indexOf als includes-Ersatz eigentlich schon. Es kommt garantiert auch in jeder Menge Alt-Code vor, und da ist es vielleicht gar nicht mal so schlecht, wenn man das da erläutert. Inklusive Verweis auf includes als moderne Alternative für diesen indexOf()-Spezialfall.
dedlfix.
Es gibt keine contains-Funktion in Javascript
Es gibt inzwischen String.prototype.includes.
Hello,
was habe ich gerade neu gelernt?
.split() fügt jeweils ein leeres Element hinzu, wenn die Nadel im Heuhaufen (der Kleber im Kuchen) an einer der beiden Bereichsgrenzen gefunden wird.
Bei der Erstellung von Collections (Arrays) ist darauf zu achten, ob das Ergebnis Dynaset oder Snapshot wird (Live- oder Static Collection).
Das Beispiel mit dem Ersetzen mit .split() (Lösung von Rolf b) könnten wir aufnehmen, da es sich auch zum "Highlighting von Funderstellen" in Dokumenten eignet. Außerdem bietet es eine sanfte Übergangsmöglichkeit zum mgang mit dem DOM in JavaScript.
Liebe Grüße
Tom S.
Hallo Matthias Scharwies,
Kennt jemand ein praxisnahes Beispiel, in dem man eine Teilzeichenkette mit indexOf sucht? (Suchen aller Vorkommen von 'e' oder 'has' scheint mir zu theoretisch, wenn braucht man sowas konkret?)
Wenn man JS in Abhängigkeit von der URL ausführen möchte.
if (document.URL.indexOf('Spezial:') == -1) {
$('#p-namespaces > ul').append("<li><span><a href='" + url + "' title='Frage im SELFHTML-Forum stellen‽'>Fragen</a></span></li>");
}
Oder ob ein Wort erlaubt ist.
var allowedtags = ["css", "html", "javascript", "php", "webserver"];
if(allowedtags.indexOf(tag) != -1) {
parameters['tags'].push(tag);
}
Beides aus der aktuellen common.js
Bis demnächst
Matthias
Hello,
ich finde die Beispiele aus der MDN immer ganz verständlich. Die müsste man teilweise nur ergänzen und mehr Erläuterungen geben, also auch für Anfänger verständlich machen.
Liebe Grüße
Tom S.
Servus!
Danke für eure Anregungen! Ich werde veruschen sie zeitnah umzusetzen.
ich finde die Beispiele aus der MDN immer ganz verständlich. Die müsste man teilweise nur ergänzen und mehr Erläuterungen geben, also auch für Anfänger verständlich machen.
Ja, stimmt, aber die Beispiele sind ziemlich konstruiert:
Noch besser finde ich die Selfhtml-Doku. Sie ist aktuell, aber auch da sind die Beispiele manchmal eher na ja. Über den String 'Der Mensch ist dem Mensch ein Wolf!'
im Bsp. von string.indexOf hat sich schon mal ein User wg. schlechtem Deutsch beschwert.
Mein Ziel ist es, an konkreten, praxisnahen Beispielen von einfachen Manipulationen mit JS-Zweizeilern hin zu einem komplexen Beispiel zu gelangen. Das ist mir bei anderen Tutorials imho besser als hier gelungen. Deshalb suche ich noch irgendwelche Praxisbeispiele (Zum Beispiel werden einige im DOM-Tutorial vom Spielecharakter des Beispiels abgeschreckt.).
Liebe Grüße
Tom S.
Herzliche Grüße
Matthias Scharwies
Lieber Matthias,
herzlichen Glückwunsch zu Deinem ersten JS-Tutorial!
Mir ist die inhaltliche Abgrenzung nicht ganz klar. Wenn es um das Arbeiten mit Strings geht, warum kommen dann so Sachen wie element.innerHTML = "xyz"
vor? Strings, ein Element der Sprache JavaScript, haben zunächst überhaupt keinen Zusammenhang mit dem DOM, also mit den Siebensachen, die auf einer Seite im Browser so herum hüpfen. Das Gleiche gilt für Arrays, denn auch sie sind zunächst einmal DOM-unabhängige Sprachelemente von JavaScript.
Etwas völlig anderes ist es, wenn man konkrete Anwendungsfälle "aus dem Alltag eines Webworkers" aufgreifen möchte, um zu zeigen, wie man gewisse Problemstellungen mit String-Operationen lösen kann. Dazu gehört dann z.B. die Verwendung von innerHTML
, das ja ein String ist, der sich lesen und schreiben lässt. Und dann sind auch Arrays ganz schnell ein Thema, da sie sich völlig anders verhalten, als diese NodeLists, die man von Funktionen wie getElementsByTagName
zurück erhält.
Aber das sind vielleicht sehr akademische Fragen, die den Anfänger, für den dieses Tutorial gedacht ist, nicht die Bohne interessieren.
Liebe Grüße,
Felix Riesterer.
Servus!
Lieber Matthias,
herzlichen Glückwunsch zu Deinem ersten JS-Tutorial!
Na ja, das erste ist es ja grade nicht:
das viel kritisierte Tutorial Grundlagen der Programmierung sollte ja zeigen, dass man nur mit einem Editor und Browser die ersten Schritte im Programmieren unternehmen kann. (Dauer in 8-9. Kl.: 2 Doppelstunden)
Grundlagen des DOM zeigt, wie man mit JavaScript auf das DOM zugreift, Elemente erzeugt und Klassen hinzufügt und entfernt.
Grundlagen der Ereignisverarbeitung zeigt, wie man Event-Handler an- und abhängt. Es fehlt noch ein abschließendes, komplexes Beispiel, das Bubbling und Capturing erläutert.
Bildwechsler mit der Web Animations API
Mir ist die inhaltliche Abgrenzung nicht ganz klar. Wenn es um das Arbeiten mit Strings geht, warum kommen dann so Sachen wie
element.innerHTML = "xyz"
vor?
Ja, aber das war ja grade der Kritikpunkt am ersten (Einstiegs-) Tutorial, dass die Ausgabe nicht in einer Webseite eingebettet ist. Mein Ziel wäre zu zeigen, wie Eingaben von Zeichenketten verarbeitet werden.
Hier in den ersten Beispielen die Zeichenkette als Variable vorzuhalten (var string = 'Hallo Welt!';
) halte ich für gerade noch legitim; in weiteren Beispielen sollte es dann schon eine Eingabe in einem Textfeld oder eine erhaltene E-Mail sein.
Strings, ein Element der Sprache JavaScript, haben zunächst überhaupt keinen Zusammenhang mit dem DOM, also mit den Siebensachen, die auf einer Seite im Browser so herum hüpfen. Das Gleiche gilt für Arrays, denn auch sie sind zunächst einmal DOM-unabhängige Sprachelemente von JavaScript.
Ja, aber es sollte ja, wie gesagt, ein praxisnahes Tutorial mit progressiver Komplexität werden und nicht eine Methode nach der anderen mit Ausgabe in console.log(string)
) abhandeln.
Etwas völlig anderes ist es, wenn man konkrete Anwendungsfälle "aus dem Alltag eines Webworkers" aufgreifen möchte, um zu zeigen, wie man gewisse Problemstellungen mit String-Operationen lösen kann. Dazu gehört dann z.B. die Verwendung von
innerHTML
, das ja ein String ist, der sich lesen und schreiben lässt. Und dann sind auch Arrays ganz schnell ein Thema, da sie sich völlig anders verhalten, als diese NodeLists, die man von Funktionen wiegetElementsByTagName
zurück erhält.
Genau, so was sollt's werden!
Aber das sind vielleicht sehr akademische Fragen, die den Anfänger, für den dieses Tutorial gedacht ist, nicht die Bohne interessieren.
Ja, ich lese grad ein Tutorial, dass einerseits ES6 mitbehandelt (let statt var, backticks statt Anführungszeichen), alle Methoden der Reihenfolge nach abhandelt uund dann in alert() ausgibt. So etwas machen imho unsere Methodenseiten.
Liebe Grüße,
Felix Riesterer.
Herzliche Grüße
Matthias Scharwies
Hello,
Debuggen ist nichts für Anfänger!
Debuggen ist etwas für Geduldige, die vorher gelernt haben, expliziten Code zu schreiben. Sie dürfen sich sich auch nicht mehr supertoll fühlen, nur weil sie die kürzeste, verschachtelste Schreibweise von einem ganzen Codeabschnitt einer einzigen Zeile geschafft haben.
Aber nun mal Ironie beiseite:
Zuerst sollte man die diversen Hilfsmittel genau erklärt bekommen. Das fängt beim Firefox z. B. damit an, die F12-Taste und ihre Wirkung zu kennen (ihr habt Euch ja über mich auch lustig gemacht, weil ich immer noch das Plug-In für Live-http-Headers verwendet habe). Und dann gehört sicherlich auch das Arbeiten mit (mindetens) zwei Bildschirmen dazu.
Liebe Grüße
Tom S.
Servus!
Hello,
Debuggen ist nichts für Anfänger!
Debuggen ist etwas für Geduldige, die vorher gelernt haben, expliziten Code zu schreiben.
Das klang im letzten Thread noch anders:
Dedlfix zum Thema Konsole: "Nicht selten fangen die Lernenden gleich an, selbst zu probieren (zu wünschen wäre das jedenfalls), auch Dinge, die noch nicht behandelt wurden, die sie sich einfach so zusammenreimen, und dabei sind meist auch Fehler an der Tagesordnung. Wenn man dann bereits ein Werkzeug und dessen grundlegende Bedienung kennt, mit dem man Untersuchungen anstellen kann, hilft das sowohl für das Verständnis und auch eine Vorgehensweise kennenzulernen, die man ständig braucht, denn Fehler, die man debuggen muss, hat man immer wieder."
Sie dürfen sich sich auch nicht mehr supertoll fühlen, nur weil sie die kürzeste, verschachtelste Schreibweise von einem ganzen Codeabschnitt einer einzigen Zeile geschafft haben.
Würde ein Anfänger doch nicht machen?
Ziel wäre den vorhandenen Artikel so umzuarbeiten, dass an jedem Beispiel ein kleiner Fehler mithilfe der Konsole zu finden ist.
Herzliche Grüße
Matthias Scharwies
Hello,
Sie dürfen sich sich auch nicht mehr supertoll fühlen, nur weil sie die kürzeste, verschachtelste Schreibweise von einem ganzen Codeabschnitt einer einzigen Zeile geschafft haben.
Würde ein Anfänger doch nicht machen?
<<< niemals >>> rotfl
Ziel wäre den vorhandenen Artikel so umzuarbeiten, dass an jedem Beispiel ein kleiner Fehler mithilfe der Konsole zu finden ist.
Fände ich prima! Im Fehlermachen bin ich gut ;-)
Liebe Grüße
Tom S.
Tach!
Ziel wäre den vorhandenen Artikel so umzuarbeiten, dass an jedem Beispiel ein kleiner Fehler mithilfe der Konsole zu finden ist.
var a = 23;
var b = 42;
if (a = b) {
alert('23 ist 42, q.e.d.');
}
Oft sind es die kleinen Fehler, die man übersieht, auch wenn man sich den Code dreimal anschaut. Zumindest könnte man mit einem console.log(a) vor der if-Schleife bemerken, dass der Inhalt von a noch stimmt, innerhalb dann aber den Inhalt von b angenommen hat, was nicht beabsichtigt war. Und so muss der Fehler zwischen den beiden console.log() sitzen.
var a = 23;
var b = 42;
console.log(a, b);
if (a = b) {
console.log(a, b);
alert('23 ist 42, q.e.d.');
}
dedlfix.
Servus!
Danke, @dedlfix. @all bitte liefert noch mehr, ich bau's dann ein!
Herzliche Grüße
Matthias Scharwies
Tach!
if-Schleife bemerken
Niemand hat es. 😟 Euch kann man aber auch ziemlich leicht solche Gurken unterschieben.
dedlfix.
Servus!
Tach!
if-Schleife bemerken
Niemand hat es. 😟 Euch kann man aber auch ziemlich leicht solche Gurken unterschieben.
wir haben halt alle ADHS, manche sogar AD-haha-Es.
dedlfix.
Herzliche Grüße
Matthias Scharwies
Hallo,
😟 Euch kann man aber auch ziemlich leicht solche Gurken unterschieben.
Hier im Forum stumpft man halt ziemlich ab, grade bei den regulars schaut man offenbar nicht mehr so genau hin 😟
Gruß
Kalk
Hello,
if-Schleife bemerken
Niemand hat es. 😟 Euch kann man aber auch ziemlich leicht solche Gurken unterschieben.
Ich dachte, dass das zum Witz gehört?
Liebe Grüße
Tom S.
Hallo TS,
Debuggen ist nichts für Anfänger!
Debuggen muss jeder, dessen Programm nicht das macht, was es soll.
Bis demnächst
Matthias
Hello,
Debuggen ist nichts für Anfänger!
Debuggen muss jeder, dessen Programm nicht das macht, was es soll.
Müssen heißt nicht können. Dazwischen liegen noch einige Schritte zum Verständnis. Erst wenn man die gegangen ist, kann man sich ans Debuggen machen. Ich bleibe dabei: Programmieranfänger können nicht mit "Debuggen" konfrontiert werden.
Liebe Grüße
Tom S.
Hallo TS,
Ich bleibe dabei: Programmieranfänger können nicht mit "Debuggen" konfrontiert werden.
Offensichtlich haben wir sehr unterschiedliche Vorstellungen von Debugging. Für mich bedeutet das im Anfangsstadium eine einfache Fehlerbeseitigung.
Bis demnächst
Matthias
Hello,
Ich bleibe dabei: Programmieranfänger können nicht mit "Debuggen" konfrontiert werden.
Offensichtlich haben wir sehr unterschiedliche Vorstellungen von Debugging. Für mich bedeutet das im Anfangsstadium eine einfache Fehlerbeseitigung.
Dann sind wir uns ja prinzipiell einige, nur nicht in der Begrifflichkeit.
"einfache Fehlerbeseitigung" ist "Error Handling".
Dabei wird man i. d. R. durch die Konsole unterstützt. Syntaxfehler, Zuweisungsfehler, fehlende Deklarationen/Definitionen und im Prgramm durch RÜckgabewerte (meistens einfach ignoriert).
Anfänger solten daher also erst einmal die richtige Syntax lernen und das Abfragen jedes verfügbaren Rückgabewertes!
"Debuggen" ist "Seiteneffekte oder nicht offensichtlich vorhersehbare Fehler des verwendeten Systems (IDE) oder des Programmdesigns finden und beseitigen". Dazu muss man sich überhaupt erstmal mit "Fehlern" im Sinne von "negative Rückmeldungen versa Programmversagen" auseinandersetzen.
Liebe Grüße
Tom S.
Aloha ;)
"einfache Fehlerbeseitigung" ist "Error Handling".
Auch. Aber auch ein Error ist ein Bug, dementsprechend passt der Begriff Debugging als Überbegriff hier auch.
"Debuggen" ist "Seiteneffekte oder nicht offensichtlich vorhersehbare Fehler des verwendeten Systems (IDE) oder des Programmdesigns finden und beseitigen".
Nein. Um deinem Beispiel mal absichtlich nicht zu folgen sage ich dir jetzt nicht, was Debugging für mich bedeutet. Ich wende mich dafür an Quellen. Schauen wir mal.
Wikipedia (de) [zu "Debugger"]: „Ein Debugger (von engl. bug im Sinne von Programmfehler) ist ein Werkzeug zum Diagnostizieren und Auffinden von Fehlern in Computersystemen, dabei vor allem in Programmen, aber auch in der für die Ausführung benötigten Hardware.“
Wikipedia (en): „Debugging is the process of finding and resolving of defects that prevent correct operation of computer software or a system.“
WhatIs.com: „Debugging, in computer programming and engineering, is a multistep process that involves identifying a problem, isolating the source of the problem, and then either correcting the problem or determining a way to work around it. The final step of debugging is to test the correction or workaround and make sure it works.“
W3Schools: „Searching for (and fixing) errors in programming code is called code debugging.“
Ich glaube du solltest deine stark eingeschränkte Definition nochmal in Revision nehmen - zumindest ist sie wohl nicht konsensfähig 😉
Grüße,
RIDER
Hello,
Ich glaube du solltest deine stark eingeschränkte Definition nochmal in Revision nehmen - zumindest ist sie wohl nicht konsensfähig 😉
Du hast mit deiner Interpretation des Begriffs einfach 40 - 60 Jahre zu spät angefangen.
Überleg mal, woher der Begriff "Bug" ursprünglich kam. Der hatte nichts mit logischen Programmfehlern zu tun, sondern mit Seiteneffekten, weil ein Programm aufgrund der "Bugs" nicht, wie geplant ausgeführt werden konnte. Da steckte leider eine Wanze im Relais.
Bevor er anfängt, sollte der Programmierer ein Konzeot haben, an das er sich hält.
Dann sollte der Anfänger lernen, die syntaktischen und logischen Fehler seines Programms beiseitigen zu lernen.
Dann sollte er lernen, die algorithmischen Fehler auffangen und behandeln zu lernen, also alle verfügbaren Rückgabewerte auch zu beachten und zu bewerten.
Und zum Schluss sollte er sich an das Erlernen von Debugging-Startegien machen. Das sind heutzutage solche Sachen, wie Speicherüberlauf, nicht überprüfte und/oder santitierte Eingaben, fehlende Data-Links (Kanäle, Ports, Sockets, Protokolle, usw.) , Race-Conditons, usw.
Solange Jungjuppies alle vier Stufen unter dem Deckmantel "Debugging" zusammenfassen, wird hinten nichts Sinnvolles rauskommen können. Ein Schritt nach dem nächsten bitte.
Liebe Grüße
Tom S.
Aloha ;)
Ich glaube du solltest deine stark eingeschränkte Definition nochmal in Revision nehmen - zumindest ist sie wohl nicht konsensfähig 😉
Du hast mit deiner Interpretation des Begriffs einfach 40 - 60 Jahre zu spät angefangen.
Dir ist klar, dass das eben ausdrücklich nicht meine Interpretation war, sondern die Interpretation entsprechender Nachschlagewerke, während das, worauf du dich beziehst, bisher nirgendwo außer in deiner Interpretation so nachzuschlagen ist?
Überleg mal, woher der Begriff "Bug" ursprünglich kam.
Das ist mir bewusst. Ich bin jung, nicht ahnungslos.
Deshalb weiß ich auch, dass…
Der hatte nichts mit logischen Programmfehlern zu tun, sondern mit Seiteneffekten, weil ein Programm aufgrund der "Bugs" nicht, wie geplant ausgeführt werden konnte. Da steckte leider eine Wanze im Relais.
…eine Wanze im Relais was vollkommen anderes ist als ein Seiteneffekt.
Für mich hört sich das so an als würdest du schwimmende Felle retten wollen. Genauso wie die Wanze im Relais bedeutet der umgangssprachliche Bug erstmal nur eins: Irgendwas im Programm funktioniert nicht wie es soll.
Debugging ist dann, die Wanze aus dem Relais zu nehmen - oder eben im übertragenen Sinn, einen Zustand herzustellen, bei dem das Programm dann letztendlich das tut, was es soll.
Gerne auch hierzu wieder Wikipedia: „Ein Programmfehler oder Softwarefehler oder Software-Anomalie, häufig auch Bug (englisch) genannt, bezeichnet im Allgemeinen ein Fehlverhalten von Computerprogrammen.“
Es gibt für mich und auch in allen Quellen, die ich finde, überhaupt kein Indiz dafür, dass es sinnvoll sein könnte, den allgemeinen Begriff Bug willkürlich weiter einzuschränken.
Bevor er anfängt, sollte der Programmierer ein Konzeot haben, an das er sich hält.
Dann sollte der Anfänger lernen, die syntaktischen und logischen Fehler seines Programms beiseitigen zu lernen.
Dann sollte er lernen, die algorithmischen Fehler auffangen und behandeln zu lernen, also alle verfügbaren Rückgabewerte auch zu beachten und zu bewerten.
Und zum Schluss sollte er sich an das Erlernen von Debugging-Startegien machen. Das sind heutzutage solche Sachen, wie Speicherüberlauf, nicht überprüfte und/oder santitierte Eingaben, fehlende Data-Links (Kanäle, Ports, Sockets, Protokolle, usw.) , Race-Conditons, usw.
Soweit richtig. Das sind alles Stufen des Debugging. Denn überall werden Bugs, also ungeplante Störungen in der Funktionalität des Programms behoben.
Solange Jungjuppies alle vier Stufen unter dem Deckmantel "Debugging" zusammenfassen, wird hinten nichts Sinnvolles rauskommen können. Ein Schritt nach dem nächsten bitte.
Jungjuppies? Du nimmst den Mund sehr voll dafür, dass du hier derjenige bist, der von seinem Elfenbeinturm predigt und bisher keinerlei Nachweis erbracht hat, dass irgendwas seiner Aussagen mehr ist als nur persönliches Gutdünken!
Nur gut, dass ich mich mit dem Jungjuppie nicht angesprochen fühlen muss - immerhin hatte ich ja im letzten Posting meine persönliche Meinung nicht dargelegt, sondern nur anerkannte Quellen zitiert.
Bin mal gespannt, was die Wikipedia-Community davon hält, als Jungjuppies bezeichnet zu werden. 😉
Grüße,
RIDER
Grundlage für Zitat #2219.
Hej Camping_RIDER,
Das ist mir bewusst. Ich bin jung, nicht ahnungslos.
„Auch Rost tut Not: Scharfsein ist nicht genung! Sonst sagt man stets von dir: "er ist zu jung!“
— Friedrich Nietzsche —
Marc
Lieber TS,
Solange Jungjuppies alle vier Stufen unter dem Deckmantel "Debugging" zusammenfassen, wird hinten nichts Sinnvolles rauskommen können. Ein Schritt nach dem nächsten bitte.
Liebe Grüße,
Felix Riesterer.
Hello lieber Felix,
Solange Jungjuppies alle vier Stufen unter dem Deckmantel "Debugging" zusammenfassen, wird hinten nichts Sinnvolles rauskommen können. Ein Schritt nach dem nächsten bitte.
- Das Wort "Juppie" gibt es nicht, also auch keine davon abgeleiteten Wörter wie etwa "Jungjuppie".
Dann kannst Du es ja auch gar nicht gelesen haben. Worte, die es nicht gibt, sind doch unsichtbar.
Lies den Satz bitte nochmal unter Berücksichtigung der Unsichtbarkeit. Da ist er dann zwar semantisch nicht mehr richtig, aber duchaus noch zu verstehen.
Man kann einem Auto-Fahrschüler auch nicht sagen: nun legen Sie mal den Rückwärtsgang ein, wenn der noch nichts von Schaltung, Schaltbarriere, Kupplung usw. gehört hat. Ähnlich ist es mit dem Debugger. Den kann man erst sinnvoll einsetzen/verstehen, wenn man die Grundlagen intus hat.
Liebe Grüße
Tom S.
Lieber TS,
mein Mittagessen war lecker und der Nachtisch hatte reichlich Korinthen. Da habe ich jetzt gerade genug davon. Auch Du magst wohl gerade keine mehr, denn diejenigen, die ich Dir anbot, weist Du gerade wieder zurück... Vielleicht ein Eis bei dem sonnigen Wetter?
😉
Liebe Grüße,
Felix Riesterer.
Hallo Tom,
Man kann einem Auto-Fahrschüler auch nicht sagen: nun legen Sie mal den Rückwärtsgang ein, wenn der noch nichts von Schaltung, Schaltbarriere, Kupplung usw. gehört hat. Ähnlich ist es mit dem Debugger. Den kann man erst sinnvoll einsetzen/verstehen, wenn man die Grundlagen intus hat.
Der Vergleich hinkt: Wenn ich das Autofahren lernen möchte, werde ich mich vorher bereits mit den Eigenschaften eines Autos beschäftigt haben und kann dann den Rückwärtsgang suchen und einlegen. Natürlich kann ich den Motor immer noch abwürgen, wenn mir noch das Feingefühl mit der Kupplung fehlt, aber das ist Übungssache und ich kann erkennen, was ich falsch gemacht habe und mich verbessern.
Auf das Programmieren übertragen, bedeutet das, dass auch ein Anfänger seine Programme, die auf vorher erlernten Wissen basieren, debuggen muss, indem er beim Auftreten von Fehlern einen Blick ins Error-Log des Interpreters oder des Compilers wirft und dann anhand des vorher bereits erlangten Wissens um die Syntax der Sprache oder der Logik seinen Fehler zu lokalisieren und zu beheben versucht.
Auf welchem Niveau das Debuggen stattfindet, hat keinen Einfluss darauf, wie man den Vorgang nennt.
Gruß
Julius
Hallo TS,
"einfache Fehlerbeseitigung" ist "Error Handling".
Error Handling ist nach meinem Verständnis das Reagieren auf Bedienfehler. Debugging ist das Beseitigen von Programmierfehlern, also all das, was du in m1692512 beschreibst.
Bis demnächst
Matthias
Hallo Matthias,
"einfache Fehlerbeseitigung" ist "Error Handling".
Error Handling ist nach meinem Verständnis das Reagieren auf Bedienfehler.
Fehler aller Art (hence the word). Kann ja auch ein Netzwerk-Fehler vorliegen, oder die Festplatte kann voll sein. Oder, oder, oder.
Debugging ist das Beseitigen von Programmierfehlern
Das ist die allgemein verbreitete Definition, ja.
Ansonsten ist es natürlich nicht besonders konstruktiv, einem Anfänger zu sagen „du hast einen Fehler in deinem Code? Lern erstmal die Grundlagen!” Debuggen muss zwangsläufig jeder.
LG,
CK