Feedback

C# - Encoding Type einer Textdatei bestimmen

Veröffentlicht von am 13.07.2017
(2 Bewertungen)
ermittelt den encoding type einer text datei
public static string GetEncodingTypeAsString(string filePath)
{
    string typeAsString = string.Empty;
    using(StreamReader sr = new StreamReader(filePath, true))
    {
        sr.Peek();
        typeAsString = sr.CurrentEncoding.BodyName;
    }
    return typeAsString;
}
Abgelegt unter fileencodingtype.

29 Kommentare zum Snippet

timonator schrieb am 05.09.2017:
Ich frage mich, warum "immer" nur olle Strings ausgegeben werden,
das macht den code nur unflexibel!
Grüdsätzlich sollte ein Datentyp erst dann konvertiert werden, wenn es nötig ist!
public static System.Text.Encoding GetEncodingType(string filePath)
{
using (StreamReader sr = new StreamReader(filePath, true)) {
sr.Peek();
return sr.CurrentEncoding;
}
}

this.Text == GetEncodingType("C:\\File.txt").BodyName

Übrigens ist 'filePath' als Parametername, wesentlich passender als 'fileName', weil es wirklich beschreibt, worum es sich handelt, nämlich einen Pfad.
Thomas Etzelsdorfer schrieb am 06.09.2017:
nun ja, in meinem Fall hab ich einen string benötigt, deswegen string als Rückgabetyp.

Hätte ich jetzt ein char[] benötigt ( was nicht sehr viel Sinn machen würde ) hätte ich es so gelöst das ich ein char[] returne.

mit "filename" hast du absolut recht...
timonator schrieb am 07.09.2017:
"nun ja, in meinem Fall hab ich einen string benötigt, deswegen string als Rückgabetyp."

Die Methode heißt 'GetEncodingType', also sollte sie auch genau das machen !
Angenommen, du brauchst im späteren Entwiklunsprozess einen Encoding Typ, konvertierst du dann den String zurück ?
Daher: 'Grüdsätzlich sollte ein Datentyp erst dann konvertiert werden, wenn es nötig ist!'
timonator schrieb am 10.09.2017:
Ich nochmal.
Das Snippet ist durch den einen Umstand, daß es einen schnöden String ausgibt, nicht zu empehlen !
Diese Verfahrensweise wiederspricht dem OOP Prinzip und ist mindestens als schlechter coding-stil zu betrachten.
Und schlechter Code muss nicht unbedingt verbreitet werden, das führt nur dazu, daß die gleichen Fehler, immer und immer wieder gemacht werden. Daher fände ich es gut, wenn du Kritikt auch ernst nehmen würdest.

Nochmal, falls das nicht ganz klar geworden ist:

wasauchimmer.Text == GetEncodingType("C:\\File.txt").BodyName
Da hast du deinen benötigten String, wenn du im Programmverlauf aber auch mal das Encoding brauchst, musst du nicht wieder zurück konvertieren, sondern verwendest:
wasauchimmer.Encoding== GetEncodingType("C:\\File.txt")

Ich hoffe, die Unsinnigkeit eines Strings als Funktionsausgabe wird damit deutlich.

Koopakiller schrieb am 12.09.2017:
IMO scheitert es hier eher am Namen als am Inhalt. GetEncodingType klingt für mich im ersten Moment so, als würde ich einen System.Type erhalten, was sogar passen kann, da die Encodings von System.Text.Encoding abgeleitet sind.

Nun gibst du den Namen zurück, wobei GetEncodingBodyName (eventuell auch noch GetEncodingName) bessere Namen wären.

GetEncoding würde dann entsprechend das Encoding-Objekt zurück geben.

Wenn man das Ganze als Erweiterung in irgend einer Form erstellt, können die Namen u.U. auch noch vereinfacht werden. Beispiel: FileEncodingHelper.GetBodyName

Und damit ist die Rückgabe eines Strings eben nicht unbedingt falsch oder ein schlechter Stil. Der Name muss aber passen. Der Rest ist von der Umgebung abhängig. Und jemand der ein Snippet kopiert ohne es zu verstehen und ggf. anzupassen wird es sowieso nicht schaffen ordentlichen Code zu schreiben.

BTW, wenn wir schon bei schönem Code sind: Ich hätte es so geschrieben:
public static string GetEncodingBodyName(string filePath)
{
using(var sr = new StreamReader(filePath, true))
{
sr.Peek();
return sr.CurrentEncoding.BodyName;
}
}
Wobei das natürlich Geschmackssache ist.

Ach und fileName ist je nach Definition genauso richtig wie filePath. Denn der Name kann auch den Pfad enthalten. In .NET/Windows: Ist keiner angegeben, wird im aktuellen Arbeitsverzeichnis gelesen - es ist also nicht mal ein Pfad notwendig.
Ich weiß, es ist kompliziert. Man muss leider bei jeder neuen API in die Doku gucken um zu wissen was gemeint ist. Daher: Doku ist wichtiger als Namen, und wenn man an den StreamReader-Konstruktor verweißt.
timonator schrieb am 12.09.2017:
"Und damit ist die Rückgabe eines Strings eben nicht unbedingt falsch oder ein schlechter Stil."
Eben doch !
Der OOP Gedanke bleibt dabei vollkommen auf der Strecke und das ganze ist derbe unflexible. Angenommen du braucht mal eben einen anderen Aspekt des Encodings, baust du dann jedesmal eine Zurückkonvertiermethode ? ;)
Also ich nicht.:
public void StringsSindDasEndeDerNahrungskette()
{
ListBox1.Items.Add(GetEncoding("C:\\file.txt").BodyName);
ListBox1.Items.Add(GetEncoding("C:\\file.txt").EncodingName);
ListBox1.Items.Add(GetEncoding("C:\\file.txt").IsBrowserDisplay.ToString);
ListBox1.Items.Add(GetEncoding("C:\\file.txt").IsBrowserSave.ToString);
// u.s.w.
}


"Ach und fileName ist je nach Definition genauso richtig wie filePath. Denn der Name kann auch den Pfad enthalten."
Da muss ich auch widersprechen.
Der Pfad enthällt auf jeden Fall den Namen, der Name enthällt in der Regel, aber nicht den ganzen Pfad, die Ausnahme stellt ein relativer Pfad im selben Ordner dar.
Daher unterscheide ich, bei der Beanmung, exlizit zwischen Pfad und Dateiname.

[edit=Anmerkung zum code]In der Regel habe ich auch keine Strings in Listboxen, sondern FileInfos, anzeigen lasse ich mir dann die DisplayMember und wieder ist das viel flexibler als Strings.[/edit]
Koopakiller schrieb am 12.09.2017:
Nein, wenn ich einen anderen Aspekt brauche und ich kenne die GetEncodingBodyName Methode, dann gucke ich wo die her kommt und baue sie um. Dann habe ich eine GetEncoding und eine GetEncodingBodyName Methode, die die andere aufruft. Oder ich verwerfe die GetEncodingBodyName-Methode vollkommen - hängt davon ab wie aufwendig es ist.
Aufwand vs Nutzen. Daher kann man vieles der OOP-Theorie auch schlicht weg vergessen.

Hier spricht gerade der Berufsentwickler, der private Hobby-Enthusiast versucht es übertrieben ordentlich zu machen; mit genau einem Ergebnis: Ich werde nie fertig. Theorie hat auch beim Entwickeln nichts mit der Praxis zu tun.

Konkret: Wenn du 10mal den Namen brauchst, weil die API die du nutzt eben diesen haben will und du eine Hilfsmethode schreibst die dir das Encoding bestimmt, was machst du dann? Da denke ich nicht mal an Performance und Redundanz (abrufen von BodyName, was ist wenn diese API sich mal ändert?), sondern eher daran, dass ich nicht jedes mal die x-te Unter-Eigenschaft abfragen will.

Zu deinem Beispiel-Code: Geht am Thema vorbei. Ich will nur den Namen und nichts anderes haben, nur dann ergibt solch eine Methode ja Sinn.
Bei einem hier geposteten Snippet wäre es zugegebener Maßen besser ein Encoding zurück zu geben, aber in einer echten Anwendung funktioniert das Beispiel eben nicht mehr. (vgl. bisher geschriebenes)
Davon abgesehen: GetEncoding mehrfach aufrufen? Geht natürlich (theoretisch sogar sehr gut). Aber wenn du überall so programmierst, dann bekommst du (praktisch) auch schnell die Quittung dafür.

Zu fileName: Kannst du gerne so machen, wer sich drauf verlässt ist aber selbst schuld.
https://en.wikipedia.org/wiki/Filename
timonator schrieb am 20.09.2017:
"10mal den Namen brauchst, weil die API die du nutzt eben diesen haben will und du eine Hilfsmethode schreibst die dir das Encoding bestimmt, was machst du dann?"

public Form1()                                                                                                               
{
InitializeComponent();
string MyFile = "C:\\file.txt";
Encoding validEncoding = Encoding.UTF8;
Encoding MyFileEncoding = GetEncoding(MyFile);
bool MyFileEncodingIsBrowserSave = GetEncoding(MyFile).IsBrowserSave;
bool MyFileEncodingIsBrowserDisplay = GetEncoding(MyFile).IsBrowserDisplay;
string MyFileEncodingName = GetEncoding(MyFile).BodyName;
if (ReferenceEquals(MyFileEncoding, validEncoding) && MyFileEncodingIsBrowserSave && MyFileEncodingIsBrowserDisplay)
{
Text = string.Format("{0} encoding {1} is valid", MyFile, MyFileEncodingName);
}
else
{
Text = string.Format("{0} encoding {1} is invalid, {2} expected", MyFile, MyFileEncodingName, validEncoding.BodyName);
}
}

Ein Aufruf pro Variable, wo liegt das Problem !?
Eine Funktion reicht vollkommen, deine Vorgehensweise ist ziemlicher Unfug, behaupte ich mal so als 'Hobby-Enthusiast'.
Koopakiller schrieb am 20.09.2017:
Einen Teil deines Codes könnte man auch wieder super in eine GetEncodingBodyName-Methode auslagern (nach dem Schema: jede Funktion macht nur eine Sache) ...

Weißt du wie langsam Zugriffe auf das Dateisystem sind? Jedes mal beim Aufruf von GetEncoding wird auf relativ langsame Hardware zugegriffen. Dazu kommen Lock-Systeme usw. vom Dateisystem- und Betriebssystem. Das ist unglaublich inperformant im Vergleich zum restlichen Code.

Es gibt Performance-Flaschenhälse bei denen man 2mal überlegt ob sich eine Optimierung wirklich lohnt. Und es gibt Dinge wie Dateisystem-Zugriffe.

Was war das größte professionelle Projekt an dem du jemals beteiligt warst? Mitgeschrieben habe ich an mittelgroßen Projekten (ein paar Hundert Code-Dateien), teilweise gelesen aber auch ganz große wie .NET.
Es gab dann bei mir irgendwann einen Umbruch von Gelerntem zu Erfahrenem.
Gucke speziell in den .NET Code. Es wird überall so gehandhabt. Fast keine public-Methode macht einfach so ihre Aufgabe, sondern ruft Sub-Routinen auf.
timonator schrieb am 20.09.2017:
Sorry, die Variablen müssen natürlich als static deklariert werden,
warum ist dir BerufsProProgger das denn nicht aufgefallen ? Ach ja, das wäre beim rechthaben hinderlich, verstehe.
Ich bin raus hier, viel Spass mit deiner "für jeden Scheiß eine eigene Methode" Vorgehensweise.
Koopakiller schrieb am 20.09.2017:
Welche Variablen? Und wenn du mir so kommst: Variablen können nicht static sein. [1]
Vielleicht übersehe ich es einfach noch immer: Bin aber auch nur ein Mensch. Darf auch Fehler machen.

Vor 5 Jahren habe ich auch nicht gedacht, dass man fürs Programmieren Erfahrung braucht...
Kein Problem, aber ich habe die Lehren anderer in mich aufgenommen.

[1]: https://docs.microsoft.com/de-de/dotnet/csharp/language-reference/keywords/static
timonator schrieb am 20.09.2017:
Meine Fresse, wills du mich veräppeln, oder schaffst du es etwas nicht, etwas mitzudenken ?
die vormals Variablen, mussen static deklariert werden, damit sie eben keine Variablen mehr sind !
Auf die Leeren die du genossen hast, kann ich verzichten, da ist scheinbar nicht viel mit los.
Koopakiller schrieb am 20.09.2017:
Ich kann sehr wohl denken, aber für eine ordentliche Debatte muss man auch auf seinen Kontrahenten eingehen. Ich weiß wirklich nicht was du meinst, zitiere doch einfach die Codestelle.

Außerdem: Es gibt keine static Variablen! Ich kann nicht wissen was du meinst, wenn du nicht die richtigen Begriffe benutzt.

Du kannst auf die /Le[eh]ren/ verzichten, ich nicht auf das mir gelehrte ;)

Nimm nachfolgendes bitte nicht persönlich, es sind einfach meine ungefilterten Gedanken: "Wie alt ist der? (Profilbild?), kann nicht Argumentieren, kein ordentlicher Umgangston, wiederholt sich. Eigentlich kann ich mir weitere Antworten sparen."
Denke mal drüber nach, die Summe der Stichpunkte frustriert mich...
timonator schrieb am 21.09.2017:
Ganau das Verhalten, meine ich, du gibst dir echt Mühe, dein Gegenüber nicht zu verstehen.
Ich sagte "Mitdenken", nicht "Denken" uns so viele Variablen gibts da nicht, die man gegen Konstanten austauschen könnte, guck doch selber mal nach.

Wie alt bust du denn ? Unendlich alt, oder was soll dein Avatar bedeuten ?
Ach ja, der "ordentliche Umganston"; was soll das sein ?
Und daß du meinst, ich könne nicht argumentieren, ist echt lustig, hast du ch kein einziges sachliches Argument vorweisen können; "Hier spricht gerade der Berufsentwickler, der private Hobby-Enthusiast versucht es übertrieben ordentlich zu machen ...", "Was war das größte professionelle Projekt an dem du jemals beteiligt warst? Mitgeschrieben habe ich an mittelgroßen Projekten ...", ist arrogante Pseudoargumentation, nichts weiter.
"Eigentlich kann ich mir weitere Antworten sparen."
Da kann ich nur zustimmen ! ;)
Koopakiller schrieb am 21.09.2017:
const und static. Lerne C#, dann reden wir weiter darüber.
Und das verfehlt wiedermal das Thema (das meine ich mit Argumentieren, etc.), denn ob const oder nicht tut hier nichts zur Sache. Des weiteren wären vielleicht Einstellungen/Settings besser als const.

Verstehe doch bitte dass es die Summe der Punkte ist die mich nachdenklich macht. Nichts davon war als Kritik an dich persönlich formuliert. Es sollte dich zum nachdenken bringen.

Was du so als Pseudoargumentation verstehst hat was mit Erfahrung zu tun. Was besser funktioniert kann man nicht immer in der Theorie abschätzen. Trage etwas zu einem großen Open Source Projekt bei und verstoße gegen die Code Guidelines, irgendwann merkt man sich dann wie man etwas machen sollte damit es nicht automatisiert abgelehnt wird.
timonator schrieb am 21.09.2017:
"const und static. Lerne C#, dann reden wir weiter darüber."
Damit bestätigst du meine Aussage nochmal, danke dafür !
Koopakiller schrieb am 21.09.2017:
Sorry. Jetzt hast du dich endgültig blamiert. Kannst mich gerne korrigieren. Was ist denn der Unterschied? Kennst ihn ja scheinbar nicht.

Do not feed the troll.
Thomas Etzelsdorfer schrieb am 21.09.2017:
ach du meine Fresse was ist den hier los?

@timonator: da kann man ruhig mal klatschen... wie kann man sich nur über ein "simples" Snippet so aufregen...
Das ist kein Algo der goldene Eier sch.... (legt)

Ich bin immer für Kritik offen, weil es einen weiter bringt und man was daraus lernen kann, aber Junge...sowas was du da abziehst ist LÄCHERLICH³.


timonator schrieb am 23.09.2017:
@ Sherlock Super Pro Progger
Statisch und Konstant haben vollkommen unterschiedliche Bedeutung, du hast rech .....nicht.
Das ich mich da vertan habe ist durchaus nachvolziebar, wenn man denn will, du aber nutzt sowas gleich, um deine vermeintliche Überlegenheit zu forcieren, anstatt vieleich mal eben aufzuklären.
Was mir beim überfliegen, aufgefallen ist:
"Außerdem: Es gibt keine static Variablen!"
Doch, genau die gibt es.:
https://de.wikipedia.org/wiki/Static_(Schl%C3%BCsselwort)

@Thomas Etzelsdorfer

Ich wollte verhindern, das schlechter coding stil verbreitet wird und habe das auch argumentiert.
Ab "Hier spricht gerade der Berufsentwickler, der private Hobby-Enthusiast versucht es übertrieben ordentlich zu machen" wurde es dann unsachlich, das ist einfach der Versuch, sich über den anderen zu stellen, um nicht sachlich argumentieren zu müssen, auf sowas reagiere ich alergisch !

Wer hier lächerliches abzieht, solltest du nochmal überdenken, und ich heiße auch nicht "junge". ;)
Koopakiller schrieb am 23.09.2017:
@timonator
Ich habe dich mehrfach darauf hingewiesen, dass an deiner Formulierung irgend etwas nicht stimmt und ich es somit nicht verstehe. Wenn du nicht drauf eingehst kann ich auch nichts dafür.

Wenn dir mein Formulierungsstil dazu nicht gefällt: Ich bin anfangs davon ausgegangen, dass jemand der mit Code Stil argumentiert auch die richtigen Begriffe kennt. Entsprechend habe ich nicht alles zu Ende ausformuliert. Meiner Meinung nach war es aber trotzdem verständlich.

Und auch die Wikipedia kann Fehler enthalten. Ich verlinkte oben die offizielle C# Referenz, wem sollte man wohl mehr Vertrauen?
Die "Dinger" in Klassen die aussehen wie Variablen sind Felder. Entsprechend gibt es "static fields" aber keine "static variables".

Zitat aus Link [1]:
Der Modifizierer static kann mit Klassen, Feldern, Methoden, Eigenschaften, Operatoren, Ereignissen und Konstruktoren verwendet werden [...]

Das steht gleich im ersten Absatz drin. Hast dir also die Seite scheinbar nicht mal angesehen...

"Wer hier lächerliches abzieht, solltest du nochmal überdenken"
Dito.

[1]: https://docs.microsoft.com/de-de/dotnet/csharp/language-reference/keywords/static

PS: "@ Sherlock Super Pro Progger" Wer es nicht mal schafft meinen Namen zu zitieren....oder sollte ich mich gar nicht angesprochen fühlen? In meiner Interpretation fühlst du dich schon wieder persönlich angegriffen und versuchst es zurück zu geben. Du willst ja auch nicht "junge" sein...
Du widersprichst dir selbst...jaja, ich weiß: do not feed the troll ;)
timonator schrieb am 23.09.2017:
"Ich habe dich mehrfach darauf hingewiesen, dass an deiner Formulierung irgend etwas nicht stimmt und ich es somit nicht verstehe."
Ne, du hast eher jede Gelegenheit genutzt, um mich doof darstehen zu lassen, eine ernsthaftes nachhacken, zum besseren Verständnis, sieht ander aus.

"static fields" aber keine "static variables"
Ok, da hast du recht. Ich bin meiner Fehlanname auf die schliche gekommen. Da ich meist VB progge und mich auf VS verlasse, wurde ich wohl in die Irre gefühtr.
https://picload.org/image/dgaciwia/static_var.png

"PS: "@ Sherlock Super Pro Progger" Wer es nicht mal schafft meinen Namen zu zitieren..."
Das wahr natürlich Absicht und kein unvermögen, was dir natürlich auch klar ist, aber eine Gelegenheit, sein Gegenüber für blöde zu erklären, darf natürlich nicht ausgelaasen werden ! ;)
Damit wollte ich auf deine Schlußfolgerung, die du aus meinem Avatar gezogen hast und die auch wieder nur dazu dient, deine vermeidlich Überlegenheit zu betonen, anspielen. Überheblichkeit, dient mit nichten der Aufklärung ! Du rallst das aber scheinbar kein bischen und machst einfach weiter so.
Koopakiller schrieb am 23.09.2017:
"Welche Variablen?" schrieb ich, aber du wurdest ja gleich persönlich. Ich spielte leider noch zu sehr mit.
Aber wer so überheblich schreibt und meint Recht haben zu müssen...

Ich wahr IMO nicht überheblich sondern habe aus meiner Erfahrung geschrieben. Das habe ich ebenfalls so dargelegt. Wenn du es falsch verstanden hast...kann es mir egal sein.

Wer sich selbst widerspricht kann das im Nachhinein natürlich als "mit Absicht" dastehen lassen. Das es Absicht gewesen sein soll sehe ich anders, denn hier: Wer absichtlich gegen seine eigenen Forderungen verstößt hat einen gewaltigen Denkfehler. (Kategorischer Imperativ)

Und ich habe nichts nur aus deinem Avatar geschlossen, noch nicht mal aus der Summe der aufgezählten Punkte (die viel wichtiger ist als das Profilbild, das ich nicht ohne Grund mit einem ? versehen habe). Du solltest dir das durch den Kopf gehen lassen, ich habe daraus keine Bewertung gemacht. Du hast nicht verstanden, was ich schrieb.

Ich schreibe viel aus meiner Erfahrung heraus. Und nein, ich bin nicht "unendlich alt" sondern auch erst 21, aber seit 6 Jahren Programmierer und seit 4 Jahren sogar Microsoft MVP, auch Microsoft MCC etc. Ich glaube genug Reputation zu haben um auch mal die Regeln zu hinterfragen und anderen abseits des Standards ordentlich helfen zu können. Selbst die Microsoft Entwicklerteams haben kein Problem damit und in den MSDN Foren gab es stets viel Lob dafür. Nur du maßt es dir an mich dafür zu kritisieren...
(Beweise? Google meinen Namen)
timonator schrieb am 23.09.2017:
""Welche Variablen?" schrieb ich, aber du wurdest ja gleich persönlich. Ich spielte leider noch zu sehr mit."
Die Variablen, in dem von mir geposteten Code natürlich.
Das war dir bestimmt auch vollkommen klar, doof scheinst du ja nicht zu sein. Ergo war das reine Retorik und eben keine ernst gemeinte Frage.

"Und ich habe nichts nur aus deinem Avatar geschlossen"
Was hast du denn sonst mit der Erwähnung des Avatars bezweckt ?
Du wolltest mich als unwissenden Jünglig dastehen lassen, das ist sowas von offensichtlich !

Die Angeberei geht auch gleich weiter, ich kotze gleich !
Dein Status interessier mich Scheiß !

Für hat sich die Sache hier erledigt, schöhnen Tag noch.
Koopakiller schrieb am 23.09.2017:
Klar dachte ich an deinen Code, habe den auch nochmal durchgelesen. Aber was sollte man daran auch static machen? Aus offensichtlichen Gründen habe ich es nicht verstanden.

Ich wollte damit bezwecken, dass du mal drüber nachdenkst wie du auf andere wirkst. Für mich wirkst du sehr jung und unerfahren. Hätte ich mich getäuscht hättest du mir wohl widersprochen.

Wenn das Angeberei gewesen sein soll...tut mir leid, ich wollte dir begreiflich machen warum ich so geschrieben habe wie ich es eben tat. Du willst keinen Rat annehmen. Man kann niemanden zu seinem Glück zwingen. Bleibe weiter bei deiner Theorie und lerne nicht dazu.
timonator schrieb am 23.09.2017:
"Ich wollte damit bezwecken, dass du mal drüber nachdenkst wie du auf andere wirkst. Für mich wirkst du sehr jung und unerfahren. Hätte ich mich getäuscht hättest du mir wohl widersprochen."
Es sollte in einer Diskusion doch um Inhalte gehen, was hat das Alter damit zu tun !? Daher habe ich mich darauf erst gar nicht eingelassen !
Wenn du es unbedingt wissen wills; Theoretisch könnte ich locker dein Papa sein. ;)

Ich schlage vor, daß wir das jetzt erstmal ruhen lassen, das führt zu nichts, der Entopf muss erstmal abkühlen. In einer Woche, oder so, können wir ja nochmal weiter diskutieren.
Koopakiller schrieb am 23.09.2017:
Natürlich sollte es um Inhalte gehen, das Erfahrung wichtiger als Theorie ist muss man beim Programmieren aber begreifen. Daher schrieb ich, dass ich Berufsentwickler bin und fragte explizit nach deiner Erfahrung. Dass du das in den falschen Hals bekommen hast...

Lasse deinen Eintopf ruhig abkühlen, meiner wurde nie warm ;)
Wobei ich nicht weiß welche Zutat noch fehlt, von daher können wir das von mir aus hier wirklich endlich beenden. Das Problem sollte sich ja geklärt haben.
timonator schrieb am 23.09.2017:
"das Erfahrung wichtiger als Theorie ist muss man beim Programmieren aber begreifen."
Kommt auf die Erfahrungen an, wenn ich z.B. beobachte, was im IT bereich so gelehrt wird, dann kann ich nur sagen, daß man nach so einer Ausbildung, jede menge Mist verinnerlicht hat, den man sich mühsam wieder abgewöhnen muss. Außerdem ist Erfahrung, ohne Theorie nichts, genau wie Theorie ohne Erfahrung nichts ist.

"Lasse deinen Eintopf ruhig abkühlen, meiner wurde nie warm ;)"
Du kapierst es nicht, oder ? Dabei hast du doch selbst Kants Prinzip des "Kategorischen Imperativ" erwähnt,aber wohl nicht wirklich verinnerlicht !? Wieder reine Überheblichkeit und die unfähigkeit, sich selbst an das zu halten, was man von anderen erwartet.
Ich habe deinen Vorschlag, über das eine , oder andere nochmal nachzudenken, ernst genommen, dir scheint das schwer zu fallen.
Ist wahrscheinlich ganz normal, in deinem alter dachte ich auch, ich hätte den Durchblick, das ändert sich aber meist in der nächsten Dekade.
Das jetz zu lesen, fühlt sich komisch an, stimmts ?
Koopakiller schrieb am 23.09.2017:
Klar spielt die Theorie eine wichtige Rolle. Ich kenne leider genug Leute die halbwegs programmieren können, die aber zu sehr an dem in der Uni gelerntem festhalten. Praxis sehe ich daher als wichtiger an. Aber ohne Theorie geht's natürlich nicht.

Gut, dann erkläre mir was ich nicht kapiere. Nenne meine Art ruhig überheblich, damit kann ich sehr gut leben. Zumal 95% meiner Bekannten mich eher als Zurückhaltend beschreiben. Finde ich interessant.

"die unfähigkeit, sich selbst an das zu halten, was man von anderen erwartet"
Dann nenne mir bitte genau was du meinst. Zitiere 2 Stellen die sich widersprechen bzw. die Forderung und die Stelle an der ich ihr nicht nachkomme.

"Das jetz zu lesen, fühlt sich komisch an, stimmts ?"
Passt perfekt zu dem anderen was du so geschrieben hast.
Martin Dauskardt schrieb am 27.10.2017:
Zur Theorie: In der Theorie sind Theorie und Praxis das selbe.
In der Praxis sind sie es nicht :-)

Zur Erfahrung: Wenn man seit Jahren die gleichen Fehler macht, werden sie nicht besser.

Murphy: Wenn etwas schiefgehen kann, wird es schief gehen.
 

Logge dich ein, um hier zu kommentieren!