AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Programmieren allgemein EMB DCE 12 - Bedingungen mit einen Assign-Zeichnen
Thema durchsuchen
Ansicht
Themen-Optionen

EMB DCE 12 - Bedingungen mit einen Assign-Zeichnen

Ein Thema von paule32.jk · begonnen am 9. Okt 2024 · letzter Beitrag vom 25. Nov 2024
Antwort Antwort
Benutzerbild von jaenicke
jaenicke

Registriert seit: 10. Jun 2003
Ort: Berlin
9.960 Beiträge
 
Delphi 12 Athens
 
#1

AW: EMB DCE 12 - Bedingungen mit einen Assign-Zeichnen

  Alt 11. Okt 2024, 12:19
Ja genau, aber ich halte das eben immer für falsch, korrigiert mich wenn es Fälle gibt, wo dies wirklich logisch Sinn macht.
Naja, also ich habe schon öfter Code wie diesen:
Delphi-Quellcode:
CallResult := CallAPI(...);
if CallResult = 0 then
  Result := ...
else
  raise ESevereError.Create('Fehlercode: ' + CallResult.ToString);
Ich finde es aber immer besser, wenn man einzelne Befehle auch separat schreibt, damit es übersichtlicher ist. Insofern würde ich das ohnehin nicht zusammenfassen wollen. Also so nach dem Motto:
Delphi-Quellcode:
if CallResult := CallAPI(...) then
  raise ESevereError.Create('Fehlercode: ' + CallResult.ToString)
else
  Result := ...
Theoretisch wäre das mit Pascal-Syntax durchaus umsetzbar, ohne dass es dort Mehrdeutigkeiten gäbe. Die automatische Umwandlung des Zahlenwerts in einen Boolean wäre noch zusätzlich nötig. Sonst müsste es so gemacht werden: if (CallResult := CallAPI(...)) > 0 then Wie gesagt, ich würde es nicht wollen.
Sebastian Jänicke
AppCentral
  Mit Zitat antworten Zitat
Benutzerbild von smallie
smallie

Registriert seit: 8. Jan 2013
19 Beiträge
 
Delphi 10.3 Rio
 
#2

AW: EMB DCE 12 - Bedingungen mit einen Assign-Zeichnen

  Alt 11. Okt 2024, 14:51
Niklaus Wirth schrieb vor einigen Jahren:

Zitat:
Good Ideas, Through the Looking Glass
IEEE Cover Feature 2006

It has become fashionable to regard notation as a secondary issue depending purely on personal taste. This could partly be true; yet the choice of notation should not be considered arbitrary. It has consequences and reveals the language’s character.

Choosing the equal sign to denote assignment is one notoriously bad example that goes back to Fortran in 1957 and has been copied blindly by armies of language designers since. This bad idea overthrows a century-old tradition to let = denote a comparison for equality, a predicate that is either true or false. But Fortran made this symbol mean assignment, the enforcing of equality. In this case, the operands are on unequal footing: The left operand, a variable, is to be made equal to the right operand, an expression. Thus, x = y does not mean the same thing as y = x. Algol corrected this mistake with a simple solution: Let assignment be denoted by :=.

This might appear as nitpicking to programmers accustomed to the equal sign meaning assignment. But mixing up assignment and comparison truly is a bad idea because it requires using another symbol for what the equal sign traditionally expresses. Comparison for equality became denoted by the two characters == (first in C). This is an ugly consequence that gave rise to similar bad ideas using ++, —, &&, and so on.

Published by the IEEE Computer Society 0018-9162/06/$20.00 © 2006 IEEE
"There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors."
  Mit Zitat antworten Zitat
Antwort Antwort


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 06:16 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz