[FRAGE] Problem mit Array

[kkapsner]

Genau das ist das Problem - es ist abhängig davon, was b ist. Das muss nicht immer bekannt sein oder kann sich sogar von Aufruf zu Aufruf ändern. Ein Wartungsalbtraum.

 

[tsseh]

wo ist das ein problem? a=b+c; ist auch davon abhängig, was b und c ist. soll man deswegen kein + mehr verwenden?

 

[kkapsner]

Ist bei + auch ein Problem, aber hier gibt es keine Alternative, die kürzer und nicht inkonsistent ist.
Bei

var arr = [b];

kann man hald sofort sagen, was passiert.

 

[dbarthel]

Aber auch da ist doch b veränderbar! oder sehe ich das falsch?

 

[tsseh]

Bei

var arr = [b];

kann man hald sofort sagen, was passiert.

es geht ja aber nicht um

var arr = [b];

, sondern um

var b,arr = [b,b,b,...100923 mal b..., b]

 

[dbarthel]

sondern um

var b,arr = [b,b,b,...100923 mal b..., b]

na und? es werden zwei arrays definiert. warum das nicht gleich hintereinander schreiben?

 

[tsseh]

na und? es werden zwei arrays definiert. warum das nicht gleich hintereinander schreiben?

es wird eins definiert, will man ein array, mit 107347 elementen, von welchen ich in irgendeinem algorithmus später einige werte setze, mache ich entweder mit
var a=new Array(107347);
oder
var a=[];a[107346] = undefined;
oder
var a=[HIER SCHREIBE ICH JETZT 107347 MAL undefined];
welche versteht man am besten? meiner meinng nach die 1.

 

[dbarthel]

es wird eins definiert

na du, ich weiss ja nicht!

var b,arr = [...]

richtet meiner Meinung nach, zwei variablen ein, eine namens b und eine names arr, die jeweils das danach definierte array enthalten.

Ich kann ja auch

var b,c = 0;

machen, um beide vraiablen, b und c, mit 0 zu initialisieren.

 

[tsseh]

richtet meiner Meinung nach, zwei variablen ein, eine namens b und eine names arr,

ja

die jeweils das danach definierte array enthalten.

nee, nur arr

Ich kann ja auch

var b,c = 0;

machen, um beide vraiablen, b und c, mit 0 zu initialisieren.

nein, nur c, b ist nicht initialisiert

 

[dbarthel]

Na siehe da, man lernt nie aus. Danke für die neuen Erkenntnisse.

 

[kkapsner]

will man ein array, mit 107347 elementen

Da man sie sowieso noch befüllen muss, ist es ziemlich egal, ob der Array mit 107347 Elemente zu erzeugt wird oder (in der ev. rückwärts laufenden) Schleife dir richtige Größe bekommt.

Wenn man das doch mal unbedingt braucht, würde ich

var arr = [];
a.length = 10;

verwenden - ist (meiner Meinung nach) gut lesbar und man sieht sofort, was passiert.

 

[tsseh]

Da man sie sowieso noch befüllen muss, ist es ziemlich egal, ob der Array mit 107347 Elemente zu erzeugt wird oder (in der ev. rückwärts laufenden) Schleife dir richtige Größe bekommt.

das mein beispiel konstruiert ist, gebe ich ja zu

Wenn man das doch mal unbedingt braucht, würde ich

var arr = [];
a.length = 10;

da gefällt mir der konstruktor besser

 

[kkapsner]

da gefällt mir der konstruktor besser

Mir nicht aber darum geht es auch nicht. Es geht darum, was weniger fehleranfällig ist.

 

[tsseh]

Mir nicht aber darum geht es auch nicht. Es geht darum, was weniger fehleranfällig ist.

fehleranfällig ist jede zeile code
var arr = [];a.length = 10; ist nicht weniger fehleranfällig als var arr = new Array(10);
var arr = new Array(a,b,c); nicht mehr als var arr = [a,b,c];
var arr = new Array(b); mit unbekantem typ b ist genauso konstruiert wie mein beispiel, und genau wie es dort eine alternative in literalschreibweise gibt, gibt es auch für den unbekantem typ b eine lösung mit konstruktor

 

[kkapsner]

Natürlich ist jeder Code irgendwie fehleranfällig. Aber Uneindeutigkeiten erhöhen die Fehleranfälligkeit.

var arr = new Array(b); mit unbekantem typ b ist genauso konstruiert wie mein beispiel, und genau wie es dort eine alternative in literalschreibweise gibt, gibt es auch für den unbekantem typ b eine lösung mit konstruktor

Den Satz verstehe ich nicht... denn dafür:

var b = 3;
var arr = [b];

gibt es keine direkte Entsprechung mit Konstruktor (außer man macht dann ein arr[0] = b).

 

[tsseh]

dafür:

var b = 3;
var arr = [b];

gibt es keine direkte Entsprechung mit Konstruktor (außer man macht dann ein arr[0] = b).

ja,

var arr = new Array();
arr[0] = b;

ist eine zeile mehr, genau wie

var arr = new Array(123456789);

bei dir eine zeile mehr hat

 

[kkapsner]

ist eine zeile mehr, genau wie

var arr = new Array(123456789);

bei dir eine zeile mehr hat

Ja - ist aber schlechter wartbar, da wenn ich ein Element hinzufügen will entweder die Zeile lösche und dann beide Elemente in den Konstruktor schreibe oder die Zeile kopieren und den Index ändern.
Bei meiner .length brauch' ich nur die Zahl ändern, wenn ich einen andere Länge möchte...

Aber die ganze Diskussion ist müßig, da wir da niemals einer Meinung sein werden. Ich verwende den Array-Konstruktor nie, hab' das bis jetzt noch nie bereut und empfehle es deswegen allen. Literalschreibweise ist ja auch kürzer.

 

[tsseh]

Ja - ist aber schlechter wartbar, da wenn ich ein Element hinzufügen will entweder die Zeile lösche und dann beide Elemente in den Konstruktor schreibe oder die Zeile kopieren und den Index ändern.
Bei meiner .length brauch' ich nur die Zahl ändern, wenn ich einen andere Länge möchte...

von welchem fall redest du jetzt?

Ich verwende den Array-Konstruktor nie, hab' das bis jetzt noch nie bereut und empfehle es deswegen allen.

ich auch nicht, außer bei obigem fall würde ich es, wenn er nicht rein theoretisch wäre
ich empfehle es auch keinem
aber ich rate auch kenem davon ab, weil es dafür keinen grund gibt

 

[kkapsner]

von welchem fall redest du jetzt?

Davon:

var arr = []; a.length = 10;

weil es dafür keinen grund gibt

Genau hier bin ich anderer Meinung. Höhere Wartungsstabilität und Fehlerresistenz für Null Mehraufwand sind für mich ein Grund.

 

[tsseh]

Davon:

und wo ist dort weniger zu ändern, als bei var arr = new Array(10);? in beiden fällen wird die 10 durch ne 11 ersetzt, wenn du ein element mehr haben möchtest.