[JAVA] een string trimmen lukt niet

[Verwijderd]

Hoi, ik heb een invoerveld, een lijst en een add-knop. Nu wil ik als ik op de add-knop druk dat deze onderaan in de lijst getoont wordt en als er in de lijst iets geselecteerd is dat deze op die plek komt. Dit lukt allemaal. Maar nu wil ik graag dat als er in het invoerveld voor of achteraan spaties staan dat deze weggehaald worden, dit lukt echter niet. Ik heb het volgende, maar dat werkt dus niet:

code:

  void addKnop_actionPerformed(ActionEvent e)
  {
    String nieuwItem;
    nieuwItem = invoerVeld.getText();
    nieuwItem.trim();
    int n;
    n = artikelLijst.getSelectedIndex();
    artikelLijst.add(nieuwItem, n);
  }
}

[Kwistnix]

De trim() fucntie returned een kopie van de String zonder whitespaces.
Je roept de functie dus wel aan, maar je doet niets met de return value (en dat is dus juist de String die je wilt).

http://java.sun.com/j2se/...api/java/lang/String.html

[ Voor 22% gewijzigd door Kwistnix op 15-12-2005 12:46 ]

[Martkrui]

nieuwItem = invoerVeld.getText().trim()

Dat is wat je zoekt

[Creepy]

trim() geeft een string terug i.p.v. dat het gelijk wordt aangepast . Je zult het resultaat van trim weer toe moeten kennen aan newItem.

[/spuit11]

[ Voor 6% gewijzigd door Creepy op 15-12-2005 12:44 ]

[Kwistnix]

Gamma

[Verwijderd]

en hoe doe ik dan wat met de waarde die gereturned wordt? Want bijv:

void addKnop_actionPerformed(ActionEvent e)
{
String nieuwItem;
String stringZonderSpaties;
nieuwItem = invoerVeld.getText();
nieuwItem.trim(stringZonderSpaties);
int n;
n = artikelLijst.getSelectedIndex();
artikelLijst.add(stringZonderSpaties, n);
}
}

doet het ook niet

[Kwistnix]

Verwijderd schreef op donderdag 15 december 2005 @ 12:47:
en hoe doe ik dan wat met de waarde die gereturned wordt? Want bijv:

void addKnop_actionPerformed(ActionEvent e)
{
String nieuwItem;
String stringZonderSpaties;
nieuwItem = invoerVeld.getText();
nieuwItem.trim(stringZonderSpaties);
int n;
n = artikelLijst.getSelectedIndex();
artikelLijst.add(nieuwItem, n);
}
}

doet het ook niet

Java:

void addKnop_actionPerformed(ActionEvent e)
  {
    String nieuwItem = invoerVeld.getText().trim();
    int n = artikelLijst.getSelectedIndex();
    artikelLijst.add(nieuwItem, n);
  }
}

Je weet dus niet precies wat een return value is begrijp ik?

Ok:

In dit voorbeeld roep je de methode trim() aan van een willekeurig String object.
Binnen die methode worden de leading en trailing whitespaces weggehaald en de waarde van het String object wordt in een nieuw String object gestopt.
Dat String object wordt teruggegeven, zodra de methode doorlopen is.

Wanneer jij dus willekeurigeString.trim(); aanroept, wordt de methode wel uitgevoerd, maar als je dan de return value niet opvangt heb je er niets aan.

[ Voor 33% gewijzigd door Kwistnix op 16-12-2005 00:45 ]

[Verwijderd]

Jaaaaaaaaaaaaah dank je!!
nieuwItem = invoerVeld.getText().trim()

was inderdaad wat ik zocht!!

sorry voor het niveau van mijn post hoor

[Martkrui]

Verwijderd schreef op donderdag 15 december 2005 @ 12:50:

nieuwItem = invoerVeld.getText().trim()

Dat zei ik al

[bvp]

En als je het dan toch volgens je eigen conventies wilt doen.
en misschien snap je dan ook beter wat er gebeurd:

Java:

void addKnop_actionPerformed(ActionEvent e)
  {
    String nieuwItem;
    nieuwItem = invoerVeld.getText();
    nieuwItem = nieuwItem.trim();
    int n;
    n = artikelLijst.getSelectedIndex();
    artikelLijst.add(nieuwItem, n);
  }
}

Hier zie je dus heel duidelijk dat je:

- een nieuwe String definieërt > String nieuwItem
- iets in dit object String gaat zetten > nieuwItem = invoerVeld.getText();
- een trim uit gaat voeren en deze toekent aan je string > nieuwItem = nieuwItem.trim();

Uiteraard is de:
String nieuwItem = invoerVeld.getText().trim(); een heel stuk compacter

[Verwijderd]

bvp schreef op donderdag 15 december 2005 @ 13:39:
Uiteraard is de:
String nieuwItem = invoerVeld.getText().trim(); een heel stuk compacter

Maar compleet niet te debuggen. Ik prefereer daarom jou manier. Deze 'compacte' notatie is niets anders dan een slechte gewoonte

[bvp]

Verwijderd schreef op donderdag 15 december 2005 @ 13:59:
[...]

Maar compleet niet te debuggen. Ik prefereer daarom jou manier. Deze 'compacte' notatie is niets anders dan een slechte gewoonte

Wat valt er nou aan een trim() functie te debuggen???
Ik pas inderdaad ook geen eindeloze nesting toe maar zoiets simpels als een trim() functie kun je lijkt mij toch zeker wel gewoon in 1x doen....

[Kwistnix]

bvp schreef op donderdag 15 december 2005 @ 14:02:
[...]




Wat valt er nou aan een trim() functie te debuggen???
Ik pas inderdaad ook geen eindeloze nesting toe maar zoiets simpels als een trim() functie kun je lijkt mij toch zeker wel gewoon in 1x doen....

Ik vind het inderdaad nogal triviaal om die tussenstappen voor een dergelijk methode helemaal uit te schijven. Ondoorzichtelijker wordt het er in dit geval niet van IMO.

In onderstaand geval zou het een ander verhaal zijn:

Java:

void addKnop_actionPerformed(ActionEvent e) 
  { 
    artikelLijst.add(invoerVeld.getText().trim(), artikelLijst.getSelectedIndex()); 
  } 
}

[ Voor 19% gewijzigd door Kwistnix op 15-12-2005 14:31 ]

[bodiam]

bvp schreef op donderdag 15 december 2005 @ 14:02:

Wat valt er nou aan een trim() functie te debuggen???

Niet aan de trim functie, maar wel aan de regel : String nieuwItem = invoerVeld.getText().trim();

Zeker als je een beginnend programmeur bent, kun je hier een NullPointerException op krijgen. Ga dan maar eens zoeken waar het zit. Is het het invoerVeld dat niet (meer) geintialiseerd is, of is de getText() null? Het lijkt misschien een beetje overbodig, maar de meeste NPE's die ik tegen ben gekomen zaten op regels als object1.getValue().getOtherValue().print(); Zoek dan maar eens uit waar het verkeerd gaat. Dus om mee te beginnen zou ik zeker aanraden om het op meerdere regels te plaatsen.

[Hydra]

bodiam schreef op donderdag 15 december 2005 @ 14:45:

Zeker als je een beginnend programmeur bent, kun je hier een NullPointerException op krijgen. Ga dan maar eens zoeken waar het zit. Is het het invoerVeld dat niet (meer) geintialiseerd is, of is de getText() null?

Dat kun je in iedere fatsoenlijke IDE met debugger prima zien.

[Verwijderd]

Hydra schreef op donderdag 15 december 2005 @ 16:03:
Dat kun je in iedere fatsoenlijke IDE met debugger prima zien.

Je kunt het misschien wel zien maar je moet al je attributen af gaan en in dit geval getText in debug mode evalueren. Dan prefereer ik gewoon een regelnummer waarop het is fout gegaan, dan is het tenminste zonder zoeken in 1 keer duidelijk. Het gaat er dus juist om, zeker voor een beginnende programmeur, dat je de dicipline hebt om dergelijke statements te scheiden. Misschien is het voorbeeld in dit topic triviaal, maar het gaat om de dicipline. Zijn je collega's tenminste ook blij met je manier van coden.

[Janoz]

Hydra schreef op donderdag 15 december 2005 @ 16:03:
[...]


Dat kun je in iedere fatsoenlijke IDE met debugger prima zien.

..pas nadat je je applicatie in debugmode opgestart hebt enz enz.

Zet je het over meerdere regels dan krijg je een stacktrace met daarin het regelnummer x, x+1 of x+2. Zie je het gelijk.

Het enige voordeel dat je hebt is dat je source minder regels heeft en dat is IMHO niet echt een overtuigend voordeel dat alle nadelen doet verbleken. Ikzelf schrijf het dan ook in de meeste gevallen gewoon uit.

[Hydra]

Verwijderd schreef op vrijdag 16 december 2005 @ 09:47:
[...]
Je kunt het misschien wel zien maar je moet al je attributen af gaan en in dit geval getText in debug mode evalueren. Dan prefereer ik gewoon een regelnummer waarop het is fout gegaan, dan is het tenminste zonder zoeken in 1 keer duidelijk. Het gaat er dus juist om, zeker voor een beginnende programmeur, dat je de dicipline hebt om dergelijke statements te scheiden. Misschien is het voorbeeld in dit topic triviaal, maar het gaat om de dicipline. Zijn je collega's tenminste ook blij met je manier van coden.

Mijn collega's zouden gillend gek worden denk ik. We hebben wel coding conventions that niet alles op 1 regel mag (tot een lengte van 80 characters), en dat we het anders over verschillende regels verspreiden, en dan dus zo:

Java:

string line;
line = someObject
      .doSomeThing()
      .getString()
      .trim()
      .subString(x, y);

IMHO prima leesbaar. Ik vind dit:
string line;
object obj;

obj = someObject.doSomeThing();
line = obj.getString();
line = line.trim();
line = line.subString();

dus veel irritanter.

[Verwijderd]

Misschien prima leesbaar, maar nog stees lastig te debuggen. En het voegt qua aantal regels niets meer toe. En tevens is het vaak zo dat dergelijke hoeveelheid van geneste method calls er op duidt dat je methode signature niet correct is. Dus nee, een dergelijke vorm van programmeren is vrij amateuristisch.

[ Voor 9% gewijzigd door Verwijderd op 16-12-2005 10:45 ]

[jAnO!]

Remember:
Strings are immutable in Java.

Dus je zal altijd als je iets met een String doet, deze aan een nieuwe string moeten assignen.

zie ook:

http://java.sun.com/j2se/...api/java/lang/String.html

[Kwistnix]

Verwijderd schreef op vrijdag 16 december 2005 @ 09:47:
[...]
Je kunt het misschien wel zien maar je moet al je attributen af gaan en in dit geval getText in debug mode evalueren. Dan prefereer ik gewoon een regelnummer waarop het is fout gegaan, dan is het tenminste zonder zoeken in 1 keer duidelijk. Het gaat er dus juist om, zeker voor een beginnende programmeur, dat je de dicipline hebt om dergelijke statements te scheiden. Misschien is het voorbeeld in dit topic triviaal, maar het gaat om de dicipline. Zijn je collega's tenminste ook blij met je manier van coden.

Ik ben het wat dat betreft ook zeker met je eens dat het nesten van method calls meer nadelen oplevert dan voordelen. Het is gewoon een afweging die je per situatie moet maken, tenzij afspraken hierover deel uitmaken van stricte coding standards natuurlijk.

In de situatie van de TS levert het genest aanroepen van de trim() functie naar mijn mening geen wezenlijke problemen op en ik vind dat een dergelijke notatie (in dit geval) beter leesbaar is, maar dat is een persoonlijke voorkeur denk ik.

Even terzijde: hoe zie jij het gebruik van het decorator / wrapper pattern, aangezien je daarmee ook een behoorlijk diepgaande nesting mee kan creëren?