Modifier valeur TStringList

Bonjour!

Je voudrais modifié une valeur dans une TStringList.

J'ai donc créer la méthode:

var myList : TstringList;
[...]

procedure TMyObjet.changeValue(const index:word; const str : String);
begin
  if (index<=myList.Count)) then begin
    myList.Delete(index);
    myList.Insert(index,str);
  end;
end;

A prioris ça semble marché correctement (j'ajoute aussi que la TStringList n'est pas triée), mais je souhaiterais savoir si il y a une autre solution, ou si celle-çi vous semble correcte...

Merci de votre avis..

tout simplement :


procedure TMyObjet.changeValue(const index : integer; const str : String);
begin
  MyList[index] := str
end;

ou

procedure TMyObjet.changeValue(const index : integer; const str : String);
begin
  if MyList[index] <> str then
    MyList[index] := str
end;

ou

procedure TMyObjet.changeValue(const index : integer; const str : String);
begin
  if index < MyList.Count then
  { if (index < MyList.Count) or (MyList.Count = 0) then }
     MyList[index] := str
  else
     MyList.Add(Str);
end;

ensuite l'objet MyList doit appartenir a l'objet MyObject ... un objet ne doit en aucun cas (du moins la plupart du temps et dans les cas generaux) faire appel a un objet externe si ce dernier n'est pas utilisé ailleur.

TMyObjet = class({ancetre})
private
  fMyList : TStrings;
  fOnChange : TNotifyEvent;
  procedure SetMyList(val : TStrings);
protected
  procedure Change; virtual;
public
  constructor Create; {override;}
  destructor Destroy; {override;}
  property fMyList : TStrings read fMyList write SetMyList;
  property OnChange :  TnotifyEvent read fOnChange write fOnChange;
end;

constructor TMyObject.Create;
begin
  inherited Create;
  fMyList := TStringList.Create;
end;

destructor TMyObject.Destroy;
begin
  fMyList.Free;
  inherited Destroy;
end;

procedure TMyObject.Change;
begin
  if Assigned(fOnChange) then
     fOnChange(Self);
end;

procedure TMyObject.SetMyList(val : TStrings);
begin
  fMyList.Assign(val);
  Change;
end;


aussi, c'est une erreur de mettre des parentheses dans un if quand il n'y a qu'une seule condition :

correct :

if truc <= machin then
if truc in machin then
if truc then
if not truc then
if not (truc in machin) then
if not (truc = machin) then
if (X mod 2) = 0 then
if not ((X mod 2) = 0) then
if (truc <= machin) or (truc => machin) then
if (truc = machin) and (machin <> bidule) then
if CheckBox1.Checked and CheckBox2.Checked and CheckBox3.Checked then


incorrect :

if (truc <= machin) then
if (truc in machin) then
if (not truc) then
if ((truc = machin) and (machin <> bidule)) then


because Delphi is not C++

et il en vas de meme pour while ou repeat ...

---

Croc (click me)

Hello foxi,

"aussi, c'est une erreur de mettre des parentheses dans un if quand il n'y a qu'une seule condition" [...] "because Delphi is not C++"???

Je vois pas en quoi c'est une erreur et surtout en quoi sa se rapproche du C++ ?

 Tout d'abord, le compilateur l'accepte de par sa grammaire formelle :

InstructionIf -> IF Expression THEN Instruction [ELSE Instruction]
Expression -> ExpressionSimple [OpRel ExpressionSimple]...
ExpressionSimple -> ['+' | '-'] Terme [OpAdd Terme]...
Terme -> Facteur [OpMul Facteur]...
Facteur -> Désignateur ['(' ListeExpr ')']
       -> '@' Désignateur
       -> Nombre
       -> Chaîne
       -> NIL
       -> '(' Expression ')'
       -> NOT Facteur
       -> ConstructeurEnsemble
       -> IdentType '(' Expression ')'

Ensuite, d'un point de vue logique si l'on met des parenthèses avec des conditions multiples, il est normal d'en mettre également dans une condition simple.

En résumé :
  Ce n'est pas une erreur !

P.S. Pour le repeat et le while, c'est idem.

Cordialement.

---

"L'imagination est plus importante que le savoir." Albert Einstein

Ce n'est pas une erreur, c'est juste inutile. Tout comme écrire : var Bool: Boolean; begin if (Bool = True) then begin DoSomething(); end; end; car : - "if Bool = True" => "if Bool". - Pas besoin de parenthèses autour. - begin..end inutile si une seule ligne. - parenthèses à la procédure inutiles si pas de paramètres. En gros, en allégé, ça donne ça: var Bool: Boolean; begin if Bool then DoSomething; end; C'est quand même plus clair qu'avant. Et encore, j'ai pas fait le coup de l'indentation foireuse où on saute 2 lignes entre le then et le begin ... Ce ne sont que des détails, mais je pense que bien coder, c'est surtout et avant tout bien écrire. Un code fonctionnel ne suffit pas: il faut qu'il soit maintenable. Donc il fait qu'il soit lisible. Donc il faut que le gars qui code écrive bien. Donc il faut un minimum de respect quand aux nomenclatures. Voila.

"Un code fonctionnel ne suffit pas: il faut qu'il soit maintenable."

Entièrement d'accord , cependant lequel de ces deux codes :

// Code 1
var
  Bool : Boolean ;
begin
  if Bool then
    DoSomething ;
end;
 
// Code 2
var
  Bool : Boolean ;
begin
  if ( Bool ) then
  begin
    DoSomething ;
  end ;
end ;

est le plus facile à maintenir si tu as :
  - une condition à ajouter à ton if : Exemple ( a and (b+c))
  - plusieurs actions à effectuer dans ton if : Exemple, DoSomething1 et DoSomething2  

Sans hésitation, c'est le code 2.

"- "if Bool = True" => "if Bool".
- Pas besoin de parenthèses autour.
- begin..end inutile si une seule ligne.
- parenthèses à la procédure inutiles si pas de paramètres."
Dans tous ces cas, c'est avoir une vision à court terme que de ne pas mettre des parenthèses et/ou des begin..end, et donc c'est de ne pas envisager d'éventuelles futures modifications.

"Donc il fait qu'il soit lisible."
Les parenthèses, les begin..end ne gènent en rien la lisibilité, bien au contraire.

"Donc il faut un minimum de respect quand aux nomenclatures."
Je suppose que c'est aux normes que tu faisais allusions.

Cordialement.

---

"L'imagination est plus importante que le savoir." Albert Einstein

On ne doit pas avoir la même version du mot "lisible" (le code 2 est bien trop lourd à mon goût, pour le peu qu'il fait ...) mais bon, chacun fait comme il le sent après tout... Pour "norme" vs. "nomenclature" tu a tout à fait raison. Remarque, ça me permet de dire qu'utiliser une nomenclature stricte pour les noms de variables, etc améliore grandement la lisibilité.

pour ma part, je pense que vous vous prenez la tête sur des histoires de sémiologie, pourdéfendre vos points de vue respectifs (ce que je comprends tout à fait) mais...
en définitive, ça dépend du degré de complexité du code à produire, non?
enfin, je peux me tromper et je ne veux pas donner des leçons à des personnes certainement beaucoup plus efficaces que moi en matière de programmation...
sur ce, je retourne dans les entrailles de mon système... si on me demande, dites que nous ne m'avez pas vu, ok? lol
mes salutations admiratives à vous tous!

---

si Delphi m'était conté...