MSSQL und Visual Basic Tutorial?

[Osmoses]

Hallo!

Bin leider etwas zu beschäftigt um mich da durchzuwühlen, aber ich brauch für eine Kollegin ein MSSQL und Visual Basic Tutorial.

Sie ist programmiererfahren und kennt sich prinzipiell mit der Materie aus, hat aber seit knapp 7 Jahren (war noch VB 6.0) nicht mehr viel damit gemacht und sucht jetzt ein entsprechendes Tutorial.

Hat hier jemand den einen oder anderen Link?

[PatkIllA]

Auf welcher Ebene?
DataReader
DataTable, DataSets, DataView
EntityFramework

Generell SQL erfahren?
Nur ein paar Daten rausholen oder auch selbst Datenbanken anlegen, optimieren?

Das VB 6 dürfte da auch nicht so viel nutzen. Mit den .NET Unterbau ist doch einiges anders.

ADO.NET wäre aber mal der erste Suchbegriff.

[Gast]

Bei galileocomputing gibt es für VB genug kostenlose Bücher, z.B. das http://openbook.galileocomputing.de/einstieg_vb_2012/ Gibt es dort auch in der älteren Version, dafür ausführlicher, aber da hat sich nicht so arg viel geändert. Für MSSQL selbst würde ich ein Buch verwenden, da es da wichtig ist die ganzen Zusammenhänge zu begreifen, insbesondere dann wenn man DB designen und ggf. optimieren möchte oder Prozeduren schreibt. Ansonsten findet man bei MS selbst ausführliche Tutorials wie z.B.
http://msdn.microsoft.com/en-us/library/ms167593%28v=sql.105%29.aspx oder für VB http://msdn.microsoft.com/de-de/library/2x7h1hfk.aspx Die MSDN ist zwar etwas trocken, aber wenn man Vorerfahrung hat kann man das wahrscheinlich auch verwenden.
Es gibt verschiedene Vorlesungen und Folien bzw. Scripts von diversen Hochschulen, da muss man sich aber selbst durchwühlen um was gutes und aktuelles zu finden.

Letztenendes kommt es nur auf das Ziel an. Wenn es darum geht die Kenntnisse solide in der Arbeit einzusetzen ist ein Buch sowieso ratsamer als sich aus irgend einem Online-Tutorial das man vor die Nase geworfen bekommt zu speisen, das würde ich in diesem Fall nur als Referenz oder Ergänzung verwenden. Wenn es nur darum geht ein bisschen rumzuskripten oder wieder einzusteigen dann reichen die openbooks von galileocomputing vollkommen aus.

Eine halbwegs gepflegte längere Liste mit allen möglichen frei verwendbaren Tutorials ist hier zu finden: https://github.com/vhf/free-programming-books/blob/master/free-programming-books.md

[Matrix316]

Im Prinzip isses relativ einfach:

Erst mal brauch ich irgendwo her einen Connection String

data source=SQLSERVER;initial catalog=DATENBANKNAME;user id=sa;Password=xyzabc


Und dann kann ich in einer Funktion einfach zugreifen: (die hier liefert eine Abfrage in einem DataSet zurück. Ein DataSet ist eine Sammlung von DataTables. Das heißt, man kann auch fünf DataTables in ein DataSet einfügen. Oder man füllt nur eine DataTable und gibt diese zurück. Man kann auch im Prinzip nur eine DataRow zurückgeben. Jede DataTable besteht aus X DataRows)


Public Function GetSQLDaten(ByVal Variableirgendwas As Int64) As DataSet
Dim myDataAdapter As New SqlDataAdapter
Dim mySelectCommand As New SqlCommand
Dim myCon As New SqlConnection("Hier muss irgendwie der Connectionstring hin, bei Webanwendungen z.B. aus der Web.config. Man kann ihn auch direkt reinschreiben, aber wenn er sich ändert, muss man jede Funktion ändern.")
Dim myDS As New DataSet("Datenbankname")
Dim strA() As String
Dim str As String
Dim i As Integer


Try
myCon.Open()
mySelectCommand.Connection = myCon
myDataAdapter.SelectCommand = mySelectCommand

mySelectCommand.CommandText = "select * from irgendwas where ID = " + Variableirgendwas.ToString();
myDataAdapter.Fill(myDS, "Datenbankname") ' Alternativ auch mySelectCommand.ExecuteNonQuery() oder mySelectCommand.ExecuteScalar()

Catch ex As Exception
Debug.WriteLine(ex.Message)
Finally
myCon.Close()
End Try

Return myDS
End Function

Ansonsten findet man neben den üblichen Tutorials auch bei Youtube viele Hilfsvideos, z.B.: https://www.youtube.com/watch?v=D3C7wcAgSJQ

[PatkIllA]

@MAatrix316
im ADO.NET Umfeld sollte man eigentlich alles disposen.
Und für Beispiele, die einen QueryText zusammenbauen statt Parameter zu benutzer sollte man gleich gesteinigt werden. Das ist absolutes Nogo und gehört bei jeder Stelle wo eine Query verwendet drangeschrieben wird.

Um nur Daten rauszuholen würde ich den DataReader nehmen. Der braucht weniger Speicher und man kann während die Datenbank noch liest schon mit Daten arbeiten. Den SqlDataAdapter braucht man dann auch nicht.

[Matrix316]

@MAatrix316
im ADO.NET Umfeld sollte man eigentlich alles disposen.
Und für Beispiele, die einen QueryText zusammenbauen statt Parameter zu benutzer sollte man gleich gesteinigt werden. Das ist absolutes Nogo und gehört bei jeder Stelle wo eine Query verwendet drangeschrieben wird.

[...]

Und wäre der werte Herr auch so gütig zu erklären WARUM das ein Nogo ist?

Performancetechnisch sollte es 0,0% Unterschied machen.

Oder wo ist hier der Unterschied?

select * from Tabelle where ID = 1

vs


declare @VariableID int
set @VariableID = 1

select * from Tabelle where ID = @VariableID


WO es einen Unterschied machen kann ist, wenn man mit Doubles, Decimals und Währungen hantiert. Ja dann sind Parameter wohl besser.

Im Endeffekt braucht man nicht mal die Funktionen bzw. Abfragen, sondern könnte sich alles grafisch in Visual Studio zusammenbasteln. Aber um die Grundlagen für SQL zu kriegen, ist es glaube ich garnicht so schlecht die Abfragen selbst zu machen.

[PatkIllA]

Und wäre der werte Herr auch so gütig zu erklären WARUM das ein Nogo ist?

Performancetechnisch sollte es 0,0% Unterschied machen.
Schon mal was von SQL Injection gehört?

Deshalb fängt man das auch bei Integern gar nicht erst damit an.

Wenn man Commands öfter absetzt ist übrigens auch schneller, wenn man nur den Parameterwert anpasst.

[Matrix316]

Nein, hör ich zum ersten Mal, zumindest für SQL, aber das hätte man auch etwas freundlicher und begründeter schreiben können und nicht so, als ob jeder, der es althergebracht macht wie ein Volldepp aussieht. :rolleyes: :|

Ist das nicht sogar eigentlich ein Fehler bei den Parametern, dass es keine Injection möglich ist?


declare @Variable varchar(500)

set @Variable = '''123''; select * from tbl_Auftrag--'''
print 'select * from tbl_Auftrag where barcode = ' + @variable

Ausgabe Print:
select * from tbl_Auftrag where barcode = '123'; select * from tbl_Auftrag--'

select * from tbl_Auftrag where barcode = @Variable

--Der Aufruf des was Print mit der Variable macht, würde die Injection ermöglichen
--Der Aufruf mit Parameter macht das nicht

[PatkIllA]

Nein, hör ich zum ersten Mal, zumindest für SQL, aber das hätte man auch etwas freundlicher und begründeter schreiben können und nicht so, als ob jeder, der es althergebracht macht wie ein Volldepp aussieht. :rolleyes: :|Nicht dein Ernst oder? ich finde es auch seltsam, dass das in Tutorials gar nicht oder nur am Rand auftaucht. Das gehört bei der allerersten Abfrage fett dazugeschrieben, statt dessen werden fast überall die Strings zusammengebaut.

Ist das nicht sogar eigentlich ein Fehler bei den Parametern, dass es keine Injection möglich ist?Wenn es mit Parametern möglich wäre, dann wäre das ein Fehler in der Datenbankschicht.

[Exxtreme]

Und wäre der werte Herr auch so gütig zu erklären WARUM das ein Nogo ist?

Das ist eine potentielle Quelle für SQL-Injections wenn du anfängst die SQL-Anweisungen zu basteln. Kann nämlich sein, dass da etwas mitkommt was du gar nicht haben willst. Das ist mit ein Grund warum Mechanismen wie prepared statements eingeführt wurden.

[PatkIllA]

Und aufwändiger ist es auch nicht. Spätestens wenn man anfängt zu versuchen Strings zu escapen und die ganzen Formatierungsprobleme von DateTime, Gleitkomma usw zu handhaben.
als command.Parameters.AddWithValue("@param", value) zu machen.

[Matrix316]

Keine Ahnung, da wir keine "öffentlichen" Webseiten für jeden machen, sondern nur Webapps für bestimmte Kunden, hat sich hier noch niemand Gedanken drüber gemacht.

Btw. was im SQL Server aber geht (der Code von oben +)

exec('select * from tbl_Auftrag where barcode = ' + @Variable)

:naughty:

[Exxtreme]

Keine Ahnung, da wir keine "öffentlichen" Webseiten für jeden machen, sondern nur Webapps für bestimmte Kunden, hat sich hier noch niemand Gedanken drüber gemacht.

Kann bös ins Auge gehen. Denn du weiss nicht was der Kunde damit macht. Stellt er das Ding mal testweise ins Internet dann kann man per SQL-Injection sehr viele Daten rausziehen. Zudem können prepared statements schneller sein da der SQL-Server den Ausführungsplan nicht jedes Mal neu ermitteln muss wenn man die selbe Abfrage mehrmals hintereinander braucht.

[Gohan]

Keine Ahnung, da wir keine "öffentlichen" Webseiten für jeden machen, sondern nur Webapps für bestimmte Kunden, hat sich hier noch niemand Gedanken drüber gemacht.

Btw. was im SQL Server aber geht (der Code von oben +)

exec('select * from tbl_Auftrag where barcode = ' + @Variable)

:naughty:

Sorry, aber die Ausrede zählt nicht. Wenn ihr das wirklich überall so handhabt, habt ihr ein gigantisches Sicherheitsproblem in allen euren Apps. SQL Injections zu ermöglich, ist mit einer der größten Fehler den man machen kann, da stehen jedem halbwegs vernünfigem Entwickler die Haare zu berge wenn er sowas sieht.

SQL Injections zu verhindern, gehört zu den ABSOLUTEN GRUNDLAGEN.

[PatkIllA]

Das Select * würde ich mir auch gar nicht erst angewöhnen, außer wenn man mal mit einem Tool auf die Daten schauen will.

[Matrix316]

Sorry, aber die Ausrede zählt nicht. Wenn ihr das wirklich überall so handhabt, habt ihr ein gigantisches Sicherheitsproblem in allen euren Apps. SQL Injections zu ermöglich, ist mit einer der größten Fehler den man machen kann, da stehen jedem halbwegs vernünfigem Entwickler die Haare zu berge wenn er sowas sieht.

SQL Injections zu verhindern, gehört zu den ABSOLUTEN GRUNDLAGEN.
Grundlagen von was?

Wenn man in einer Firma arbeitet kriegt man garnicht so viel mit, was sich alles ändert. Man entwickelt so wie man immer entwickelt hat und wer noch nie was mit SQL Injections zu tun hatte, der weiß garnicht, dass es sowas gibt. Man ärgert sich höchstens, wenn jemand in Textfelder Hochkommas reinschreibt und dann der Insert oder Update nicht funktioniert. :freak:

Es sieht nicht jeder gleich das böse Internet alle Server übernehmen und Amoklaufen. Zumal wir wie schon gesagt, die Anwendungen nicht öffentlich ins Internetz stellen, sondern nur bestimmten Usern die Zugangsdaten brauchen. Und die haben anderes zu tun als mit SQL Injections irgendwelchen Blödsinn zu machen.

Klar, bei öffentlichen Seiten kann das durchaus ein Problem sein, aber man muss schon ziemlich viel Aufwand betreiben um sowas auszunutzen.

[PatkIllA]

Wenn man in einer Firma arbeitet kriegt man garnicht so viel mit, was sich alles ändert. Man entwickelt so wie man immer entwickelt hat und wer noch nie was mit SQL Injections zu tun hatte, der weiß garnicht, dass es sowas gibt. SQL Injection muss jeder kennen, der auch nur im entferntesten was mit Datenbanken zu tun. Man darf ja auch mal im Internet suchen und sich Informationen dazu suchen, was man überhaupt macht und nicht nur froh sein, wenn beim ersten Durchlauf gleich alles abstürzt.

Man ärgert sich höchstens, wenn jemand in Textfelder Hochkommas reinschreibt und dann der Insert oder Update nicht funktioniert. :freak:Und spätesens jetzt sollte man mal kurz ins Grübeln kommen.

Und die haben anderes zu tun als mit SQL Injections irgendwelchen Blödsinn zu machen.Iich hab auch schon aus Spass seltsam formatierte Werte in Anwendungen eingegeben.

Klar, bei öffentlichen Seiten kann das durchaus ein Problem sein, aber man muss schon ziemlich viel Aufwand betreiben um sowas auszunutzen.Nicht unbedingt. Mit etwas Erfahrung und vor allem wenn der Angreifer auch noch die Fehlermeldung sieht ist das sogar sehr einfach.

[Matrix316]

SQL Injection muss jeder kennen, der auch nur im entferntesten was mit Datenbanken zu tun. Man darf ja auch mal im Internet suchen und sich Informationen dazu suchen, was man überhaupt macht und nicht nur froh sein, wenn beim ersten Durchlauf gleich alles abstürzt.

Und spätesens jetzt sollte man mal kurz ins Grübeln kommen.

Iich hab auch schon aus Spass seltsam formatierte Werte in Anwendungen eingegeben.

Nicht unbedingt. Mit etwas Erfahrung und vor allem wenn der Angreifer auch noch die Fehlermeldung sieht ist das sogar sehr einfach.

Naja, übergabe von Parametern ist das eine, aber was im Hintergrund mit der SQL Abfrage gemacht wird, ist das andere.

Wenn ich mit einem DataAdapter einen DataSet fülle, funktionieren da die Betriebsystem execs überhaupt?

[Ganon]

Es geht mehr darum, dass du per SQL-Injektion beliebigen SQL-Code ausführen kannst. Das ist halt genauso fahrlässig wie ein Bufferoverflow.

Und das ist relativ einfach auszunutzen. Alles was du dazu brauchst ist dein Browser, mehr nicht. Über die Debug-Ansicht des Browsers kannst du dem Server jedmöglichen Scheiß schicken, unabhängig davon was du in Textfeldern erlaubst oder nicht.

http://imgs.xkcd.com/comics/exploits_of_a_mom.png

Und wer SQL-Injektion nicht kennt, der hat bestimmt auch den Rest der Datenbank nicht großartig abgesichert. D.h. sich selbst zum Admin machen ist bestimmt ein Kinderspiel.

Es sieht nicht jeder gleich das böse Internet alle Server übernehmen und Amoklaufen.

Genau das muss man aber sehen, bei der Entwicklung solcher Anwendungen. Ansonsten ist man der Falsche für den Job, ganz einfach.

Irgendwann kommt vllt. mal einer auf die Idee die Anwendungen ins Internet zu stellen, und dann? Wollt ihr dann sagen: "Ne, die ist viel zu schlecht programmiert dafür?"... das Gesicht des Anderen will ich sehen xD

[Matrix316]

Glaubt mir, ich arbeite seit 7 Jahren mit Datenbanken und noch nie hat jemand bei uns irgendwas von SQL Injections erzählt. Ich hab heute mal in die Runde gefragt und keiner wusste was.

Aber da wirs jetzt wissen, werden wirs auch berücksichtigen - irgendwann.

Unsere Anwendungen sind aber so speziell, dass die eigentlich nie öffentlich sein werden.

Btw. um drop table irgendwas zu machen, musst du erst mal wissen, was irgendwas ist und es sind nur bestimmte User vorhanden die überhaupt Rechte haben und das Passwort steht auch nicht auf der Webseite und die SQL Abfragen sind auch nicht im Quellcode Clientseitig. ;)

Außerdem geht's überhaupt um Webanwendungen oder um Windows Anwendungen? Da gibt's auch noch ein paar Unterschiede wie alles funktioniert.

[Ganon]

Außerdem geht's überhaupt um Webanwendungen oder um Windows Anwendungen? Da gibt's auch noch ein paar Unterschiede wie alles funktioniert.

Wenn du Nutzereingaben nutzt um einen SQL-String zusammenzubauen, dann hast du ein Problem.

Sicherlich schränkst du die Möglichkeiten ein, wenn du die Eingabe vorher nach Int konvertierst, aber wenn du nicht weißt was du tust, dann kann dir das auch ganz leicht bei Textfeldern passieren.

Es ist einfach die bessere Möglichkeit sowas gar nicht erst zu erlauben. Einfach Prepared Statements nehmen und gut ist. Das löst nicht nur das Problem, sondern auch noch 100 andere (' oder " in Textfeldern, oder korrekte Datumsformatierung).

[Gohan]

Glaubt mir, ich arbeite seit 7 Jahren mit Datenbanken und noch nie hat jemand bei uns irgendwas von SQL Injections erzählt. Ich hab heute mal in die Runde gefragt und keiner wusste was.

Mach dir nichts draus, das scheint leider Alltag in deutschen Programmierstuben. Ich bekomme Tag für Tag Code von Leuten vors Gesicht, die sich "Programmier" oder "Entwickler" nennen, da bekommt man das blanke grauen.

Richtig gute Entwickler sind imho sehr selten hier und entsprechend suchen wir in der Firma seit drei Jahren erfolglos nach neuem Personal, das wir nicht erst Ausbilden müssen trotz Master an der Uni + x Zertifikaten von Microsoft und Co. (Ausgewiesener .NET Experte der keine Generis kennt, unglaublich).

Sobald die meisten eine Sprache halbwegs beherrschen und damit irgendwie ein Programm runtergeleiert bekommen, hört die Interesse am Lernen meist auf und man beschränkt sich auf das was man kann. Ist zumindest mein Eindruck bisher so gewesen.

[PatkIllA]

Als ob man an der Uni wirklich programmieren lernen würde...
In drei Jahren hättet ihr aber auch selbst mal den einen oder anderen ausbilden können.

Immer die gleichen Pattern ist doch auch langweilig. Ich bin gefühlt fast genauso lang auf MSDN und Stackoverlow unterwegs wie ich am programmieren bin.

Haben wir aber auch oft. Schreiben von (sehr) guten Java und C# Kenntnissen und kriegen nicht mal einen kurzen Vergleich von beiden hin.

[Matrix316]

Man kann halt nicht alles wissen und man programmiert ja nicht um jede Programmiersprache zu 100% aus dem FF zu kennen, sondern am Ende zählt das was dabei rauskommt. Es gibt so viel Wege die nach Rom führen und man kann alles sicher noch viel besser, effizienter und sicherer machen, aber letztendlich gibt sowas wie Deadlines und dann muss ein Programm halt fertig sein und da ist es wichtiger, dass es (fehlerfrei) funktioniert, als das der Quellcode schön aussieht. ;)

[RattuS]

:facepalm:

Matrix316, nichts für ungut, aber du bist einer dieser Leute, wegen denen ich jeden Tag ein wenig mehr sterbe. Da bekommst du hier schon einen Rüffel und siehst es trotzdem nicht ein... nein, du informierst dich ja nicht einmal. "Noch nie gehört"... Doch, im 3DCenter!

Traurig sieht es mit der Softwareentwicklung aus. Jeder Entwickler, der sich nicht dafür schämt einen offensichtlichen Standard zu missachten und vor allem nicht daran interessiert ist sich zu bessern, gehört auf einen Sitzplatz in der Arbeitsagentur. Wie kann man nur so lustlos und ignorant sein?

"IT-Fachkräftemangel in Deutschland" - wen wunderts? Kein anständiges Entwicklerteam stellt Leute ein, die den Job "nur erledigen" wollen.

Du hast mindestens 7 Jahre Erfahrung und meinst, dass es nicht wichtig ist, dass der Quellcode aufgeräumt ist? Wie organisiert ihr euch denn so? 1-Mann-Projekte? :facepalm:

[Gohan]

Als ob man an der Uni wirklich programmieren lernen würde...
In drei Jahren hättet ihr aber auch selbst mal den einen oder anderen ausbilden können.

Machen wir ja auch. Dadurch bemerken die studentischen Praktikanten in der Regel recht schnell, das sie was nachholen müssen, wenn der Azubi ihnen immer erklären muss, wie etwas funktioniert ;)

... aber letztendlich gibt sowas wie Headlines und dann muss ein Programm halt fertig sein und da ist es wichtiger, dass es (fehlerfrei) funktioniert, als das der Quellcode schön aussieht. ;)

Und glaub mir, guter Quellcode ist der erste Schritt dort hin, genau das zu erreichen. Zumindest wenn man mit mehreren Leuten an einem Projekt arbeitet.

[Ectoplasma]

Und glaub mir, guter Quellcode ist der erste Schritt dort hin, genau das zu erreichen. Zumindest wenn man mit mehreren Leuten an einem Projekt arbeitet.

Bleibt nur die Frage, was man unter gutem Quellcode versteht ...
Aber allgemein stimme ich zu.

[Kenny1702]

Bleibt nur die Frage, was man unter gutem Quellcode versteht ...

Einfach das How to (https://www.thc.org/root/phun/unmaintain.html) befolgen ;)

[Matrix316]

:facepalm:

Matrix316, nichts für ungut, aber du bist einer dieser Leute, wegen denen ich jeden Tag ein wenig mehr sterbe. Da bekommst du hier schon einen Rüffel und siehst es trotzdem nicht ein... nein, du informierst dich ja nicht einmal. "Noch nie gehört"... Doch, im 3DCenter!

Traurig sieht es mit der Softwareentwicklung aus. Jeder Entwickler, der sich nicht dafür schämt einen offensichtlichen Standard zu missachten und vor allem nicht daran interessiert ist sich zu bessern, gehört auf einen Sitzplatz in der Arbeitsagentur. Wie kann man nur so lustlos und ignorant sein?

"IT-Fachkräftemangel in Deutschland" - wen wunderts? Kein anständiges Entwicklerteam stellt Leute ein, die den Job "nur erledigen" wollen.

Du hast mindestens 7 Jahre Erfahrung und meinst, dass es nicht wichtig ist, dass der Quellcode aufgeräumt ist? Wie organisiert ihr euch denn so? 1-Mann-Projekte? :facepalm:

Du kannst so viel Facepalmen wie du willst, aber Theorie und Praxis sind zwei grundlegend verschiedene Dinge.

Und wenn man anfängt in Webanwendungen massiv Javascript zu verwenden, kann man übersichtlichen Code eh vergessen. ;) Ähnliches gilt für Visual Basic. ;)

Nee, natürlich versucht man schon den Code möglichst lesbar zu handhaben, aber z.B. sowas die Kommentare und so, fallen halt manchmal unter den Tisch.

[Gohan]

Und wenn man anfängt in Webanwendungen massiv Javascript zu verwenden, kann man übersichtlichen Code eh vergessen. ;) Ähnliches gilt für Visual Basic. ;)

Das ist auch nur die halbe Wahrheit. Sicherlich, wenn man in jeder Datei <script>-Tags verteilt endet das recht schnell im Chaos. Damit hab ich bei uns bei älteren Projekten leider auch zu kämpfen und dementsprechend sind diese in der Wartung und Pflege ein graus. Leider ist derjenige, der den Code geschrieben hat nicht mehr bei uns tätig, sonst hätte der von mir schon echt was zu hören bekommen.

Auch hier gilt wieder, eine gute Organisation und eine gute Strukturierung sind die halbe Miete. Mit JavaScript lässt sich ebenso wart- und lesbarer Code schreiben wie in anderen Programmiersprachen. Es ist zwar ein wenig schwerer, aber durchaus machbar, den Code an zentraler Stelle unterzubringen.

[Coda]

:popcorn:

[Ganon]

Auch hier gilt wieder, eine gute Organisation und eine gute Strukturierung sind die halbe Miete.

Und die andere Hälfte ist eine Sprache die nach Javascript kompiliert :D Für den Anfang z.B. Coffeescript.

[Matrix316]

Das fängt schon an, dass man die öffnende geschweifte Klammer in die gleiche Zeile schreibt wie die Funktion... wer auf solche Ideen kommt...


cubes = (function() {
var _i, _len, _results;
_results = [];
for (_i = 0, _len = list.length; _i < _len; _i++) {
num = list[_i];
_results.push(math.cube(num));
}
return _results;
})();

[Ganon]

Das ist das Beispiel von der Coffeescript-Seite. Das ist der Compileroutput vom Coffeescript-Compiler und nichts handgeschriebenes.

Aber wie schon gesagt, eine Zwischensprache à la Coffeescript hilft schon extrem.

[Matrix316]

Das ist das Beispiel von der Coffeescript-Seite. Das ist der Compileroutput vom Coffeescript-Compiler und nichts handgeschriebenes.

Aber wie schon gesagt, eine Zwischensprache à la Coffeescript hilft schon extrem.
Ich weiß, aber wenn du in Visual Studio Javascript schreibst, wird das so automatisch formatiert mit den Klammern.

[Ectoplasma]

Einfach das How to (https://www.thc.org/root/phun/unmaintain.html) befolgen ;)

Nice :biggrin:

[Coda]

Das fängt schon an, dass man die öffnende geschweifte Klammer in die gleiche Zeile schreibt wie die Funktion... wer auf solche Ideen kommt...


cubes = (function() {
var _i, _len, _results;
_results = [];
for (_i = 0, _len = list.length; _i < _len; _i++) {
num = list[_i];
_results.push(math.cube(num));
}
return _results;
})();

Stimmt, ich hab das letztens im Linux-Kernel gesehen mit der Klammer in der gleichen Zeile überall. Solche Amateure, da weiß ich gleich warum ich nur proprietäre Qualitätssoftware von Microsoft und Apple verwende.

Und es wird noch schlimmer, selbst Firefox und Chrome verwenden diesen Stil, da bleibt nur die Verwendung des IE vom Weltmarktführer!

[Matrix316]

Stimmt, ich hab das letztens im Linux-Kernel gesehen mit der Klammer in der gleichen Zeile überall. Solche Amateure, da weiß ich gleich warum ich nur proprietäre Qualitätssoftware von Microsoft und Apple verwende.

Und es wird noch schlimmer, selbst Firefox und Chrome verwenden diesen Stil, da bleibt nur die Verwendung des IE vom Weltmarktführer!
Das hat glaube ich nix mit dem Browser zu tun.

Es ist halt IMO ziemlich unübersichtlich. Vor allem, wenn dann noch Funktionen als Funktionsparameter mit übergeben werden...

[Kenny1702]

Das fängt schon an, dass man die öffnende geschweifte Klammer in die gleiche Zeile schreibt wie die Funktion... wer auf solche Ideen kommt...

Ich weiß, aber wenn du in Visual Studio Javascript schreibst, wird das so automatisch formatiert mit den Klammern.

Ausgerechnet die von dir kritisierte Formatierung ist die Voreinstellung in Visual Studio (siehe Grafik oder hier (http://www.devcurry.com/2010/06/place-opening-braces-in-new-line-for.html)). Dass du/ihr es den persönlichen Vorlieben (und auch meiner) angepasst habt ist ok. Hauptsache alle machen es im Projekt gleich.

Nur euer Standard ist eben nicht der Standard (wenn es so etwas überhaupt gibt).

[Gast]

da bleibt nur die Verwendung des IE vom Weltmarktführer!
Wahrscheinlich verwenden die gar keine Klammern


if userschoice.msie11browser.IsBrowsingToMicrosoftHomePageIndex:
execute seitenaufruf ?
call muellhaufen
end else

[Matrix316]

Ausgerechnet die von dir kritisierte Formatierung ist die Voreinstellung in Visual Studio (siehe Grafik oder hier (http://www.devcurry.com/2010/06/place-opening-braces-in-new-line-for.html)). Dass du/ihr es den persönlichen Vorlieben (und auch meiner) angepasst habt ist ok. Hauptsache alle machen es im Projekt gleich.

Nur euer Standard ist eben nicht der Standard (wenn es so etwas überhaupt gibt).

Ahhhhhhhh Ok, da zitiere ich den Kommentar von der verlinkten Seite:

Thanks for the tip. I like my javascript open braces to be consistent with my c# code.

:)

Ich sag ja, man kann nicht alles wissen. Aber jetzt weiß ichs.

(Trotzdem Schwachsinn, diese Voreinstellung. Außerdem sieht man das überall so. Keine Ahnung warum und was das bringen soll, außer, dass es den Code unübersichtlicher macht...)

[Coda]

Das hat glaube ich nix mit dem Browser zu tun.
Klar, denn bei guten Browsern ist der Code mit den Klammern in der selben Zeile wesentlich schneller.

[Ectoplasma]

Klar, denn bei guten Browsern ist der Code mit den Klammern in der selben Zeile wesentlich schneller.

Ja, nicht nur bei Browsern, sondern bei jeglicher Software ist das so ... ist doch klar ...

Ich bevorzuge übrigens auch die gschweifte Klammer in der selben Zeile. Zudem ist es die Standardformatierung bei Java. Bei C/C++ mache ich es auch so. Aber das was wirklich zählt ist, dass alle im Team die gleiche Formatierung haben. In unseren Projekten wird diese dadurch erzwungen, dass z.B. beim Speichern einer Java-Datei, ein Formatierer anläuft.

[Matrix316]

Keine Ahnung, aber irgendwie finde ich mit Klammer drunter einfach lesbarer und übersichtlicher. Da weiß ich wo es anfängt und wo es aufhört. Allerdings habe ich im Studium C und C++ und C# und Javascript erst später im Beruf gelernt bzw. Java so nebenbei im Studium. ;) Im selbigen gings auch noch nicht um Webanwendungen und Browsergeschwindigkeiten und zeug.


public void funktion()
{
// dies und das
}

public void funktion() {
//dies und das
}

[Coda]

Bei deinen Apps mag das keinen Unterschied machen, aber bei Sachen wo die Performance wichtig ist macht man es natürlich in die gleiche Zeile, so wie bei JQuery, Google, Mozilla, node.js und wie sie alle heißen!

Das sind aber auch alles Amateure, die richtigen Profis schreiben so geile Algorithmen, dass es keinen Unterschied macht weil ihr Code auch so rasend schnell ist.

[Matrix316]

Bei deinen Apps mag das keinen Unterschied machen, aber bei Sachen wo die Performance wichtig ist macht man es natürlich in die gleiche Zeile, so wie bei JQuery, Google, Mozilla, node.js und wie sie alle heißen!

Das sind aber auch alles Amateure, die richtigen Profis schreiben so geile Algorithmen, dass es keinen Unterschied macht weil ihr Code auch so rasend schnell ist.

Hmmm, du meinst das wirklich ernst, oder? Wenn die Art der Klammersetzung die Performance einer Programmiersprache beeinflusst, dann ist die Programmiersprache irgendwie kaputt. ;)

Ich hab mal gegoogelt und habe nirgendwo was von wegen Performance gefunden, warum man in JS die Klammern so und nicht so schreibt.

ABER, ich hab was anderes gefunden:

http://berndschiffer.blogspot.de/2008/07/groovy-und-javascript-und-die-kunst.html

var assertEquals = function(expected, actual) {
if(expected === actual) return;
alert('AssertionError! Expected: <' + expected + '>, but was <' + actual + '>');
}

var foo = function() {
return {
key: 'value'
};
}

assertEquals('value', foo().key);

Wenn man hier die Klammern anders setzt, solls einen Fehler geben.

Aber einerseits wirds hier langsam offtopic und andererseits ein Konstruct wie


return {
key: 'value'
};


widerspricht jeglichen Genfer Programmier Konventionen. :freak:

[xxxgamerxxx]

Ausgerechnet die von dir kritisierte Formatierung ist die Voreinstellung in Visual Studio (siehe Grafik oder hier (http://www.devcurry.com/2010/06/place-opening-braces-in-new-line-for.html)). Dass du/ihr es den persönlichen Vorlieben (und auch meiner) angepasst habt ist ok. Hauptsache alle machen es im Projekt gleich.


Das glaube ich nicht. Die Einstellung müsste wenn vom Sprachprofil abhängig sein. Bei C# ist es schon die Default Einstellung.

[Ectoplasma]

Bei deinen Apps mag das keinen Unterschied machen, aber bei Sachen wo die Performance wichtig ist macht man es natürlich in die gleiche Zeile, so wie bei JQuery, Google, Mozilla, node.js und wie sie alle heißen!

Das sind aber auch alles Amateure, die richtigen Profis schreiben so geile Algorithmen, dass es keinen Unterschied macht weil ihr Code auch so rasend schnell ist.

Meinst du es jetzt wirklich ernst, oder ist das von dir nur ein böser Scherz? Die Klammersetzung beinflußt bei Javascript die Performance natürlich nicht. Wo soll bei ' ' bzw. '\n' auch eine Unterschied bei der Parser-Performance entstehen? Was anderes ist eine Javascript Minification. Bei den neueren Javascript Engines ist aber auch das scheiss egal, weil diese nativ compilieren können (siehe V8).

Ach komm ... du machst echt Scherze oder?

[samm]

Garantiert trolling, diese Klammerbehauptungen ;)