Vorteil der Verwendung von Funktionen in Programmen

[ibelieve]

Warum mag der Schreiber hier "function" verwendet haben?

Oder was hat es für Vorteile bzw. wann wird es im allgemeinen verwendet?

 

Ich habe mir hier raus eine Idee geklaut.

function Swing_Low()
{
return ValueWhen(
(L>Ref(L,-1) AND Ref(L==LowestSince(L<Ref(L,-1),L,1),-1)),Ref(L,-1),1);
}
function Swing_High()
{
return ValueWhen(
(H<Ref(H,-1) AND Ref(H==HighestSince(H>Ref(H,-1) ,H,1),-1)),Ref(H,-1),1);
}

// pot. Swing Highs, Lows
SH=Swing_High();
SL=Swing_Low();
SL= IIf(SL!=Ref(SL,1),Ref(SL,1),Null);
SH= IIf(SH!=Ref(SH,1),Ref(SH,1),Null);

 

Bei mir sieht das dann so aus.

RHL = HighestSince(Ref(H,-1)>= Ref(H,-2) AND H < Ref(H,-1),Ref(H,-1),1);
RHS = LowestSince (Ref(L,-1)<= Ref(L,-2) AND L > Ref(L,-1),Ref(L,-1),1);

 

Wo liegt der Vorteil der Funktion "function"

 

 

PS.

 

Kann man die Beiträge die hier zu gehören auch hier hin kopieren?

Danke.

http://www.tom-next.com/community/Teil-2-I...4726#entry84726

[Krümel]

Warum mag der Schreiber hier "function" verwendet haben?

Oder was hat es für Vorteile bzw. wann wird es im allgemeinen verwendet?

 

Wo liegt der Vorteil der Funktion "function"

function ist keine Funktion, sondern Du definierst damit eine Funktion und zwar die, deren Namen und Inhalt danach kommt. ;)

Warum verwendet man Funktionen:

 

1. Programme sind übersichtlicher.

 

Vergleiche mal Deine Zeile:

 

RHL = HighestSince(Ref(H,-1)>= Ref(H,-2) AND H

 

mit der Originalzeile:

SH=Swing_High();

^^

 

Man muss natürlich sinnvolle Namen für die neuen Funktionen vergeben.

 

2. Ziel ist es u.a. auch die Codelesbarkeit zu erhöhen (Zeit ist Geld), sprich: wenn man selbst oder ein anderer nach 3 Monaten reinschaut, soll er nicht genauso lange brauchen, das alles zu verstehen wie Du am Anfang, sondern möglichst einmal "durchlesen" und dann hat man grob verstanden, um was es geht. Wenn man jedes Mal so komplizierte Konstruktionen mental auseinanderfummeln muss, wie Du sie (noch^^) verwendest, dauert das bedeutend länger als wenn man abstrahieren kann und nur noch "SwingHigh" lesen muss.

 

3. Funktionen werden getestet - normalerweise ^^. D.h. Du kannst Dir hinterher relativ sicher sein, dass, wenn ein Fehler auftritt, er nicht in der Funktion auftritt. Fehlerorte ausschließen zu können ist ein Zeitgewinn. ^^

 

4. Normalerweise werden Teilaufgaben des Programms in Funktionen ausgelagert, also v.a. Dinge, die Du immer wieder machst (z.B. nen Swing-High suchen) und auch Sachen, die Du auch "nachnutzen" kannst bei späteren Programmen. D.h. Du hast nur einmal den Aufwand, ne komplexere Funktion zu schreiben und sparst das später locker wieder ein, weil Du nur noch "SwingHigh" schreiben musst statt diese Monster.

 

5. Funktionen sollen auch die Fehleranfälligkeit verringern. Guck Dir mal Deine Zeile

RHL = HighestSince(Ref(H,-1)>= Ref(H,-2) AND H

an. Stell Dir vor, Du verwendest die 3 mal in nem Programm und vertippst Dich irgendwo in einer bei ner "-1". Da suchst Du dich dusselig nach dem Fehler, kann ich Dir versprechen.

 

Oder Du merkst, dass Du 3 mal ne falsche Zeile geschrieben hast (da ist irgendwo ein Fehler drin) und eigentlich statt "H

 

Das ist jetzt bei Deinen Codemengen nicht sooo kritisch. Wenn Du jedoch größere Codemengen zu verwalten hast oder die Vorteile von Funktionen erkannt hast, dann lohnt sich das durchaus, Funktionen zu verwenden.

 

Das Ganze nennt sich "Strukturiertes Programmieren" (kannst ja mal danach googlen).

[Krümel]

Kann man die Beiträge die hier zu gehören auch hier hin kopieren?

http://www.tom-next.com/community/Teil-2-I...4726#entry84726

Ich würde den Thread gern gesondert stehen lassen, da es ein Programmierparadigma behandelt, und wir bei Tom-Next da gern contentmäßig noch nachrüsten wollen. Und solche allgemeingültigen Themen in einen von x Indikatorenthreads zu verbuddeln, wäre einfach schade.

[tlu]

@Krümel: Echt klasse Erklärung! Irgendwie war mir das zwar auch klar, aber deine Ausführungen haben dafür gesorgt, dass ich nun weiß warum

[siscop]

hallo ich kenne mich bei amibroker nicht aus aber sollte statt "function" nicht der wert des rückgabewertes dieser funktion deklariert sein? void, double, bool...? oder ist dies bei amibroker offen sobald man "function" eingibt? eine "offene" deklarierung wäre ein vorteil.

 

EDIT 13:31 oder ist amibroker so hinterher dass man dem programm noch sagen muss... hey dieser nachfolgender block ist eine funktion ... nee mal im ernst. hab gehört dass amibroker auf pascal basiert und das ist bei mir >15 jahre her

[tlu]

hallo ich kenne mich bei amibroker nicht aus aber sollte statt "function" nicht der wert des rückgabewertes dieser funktion deklariert sein? void, double, bool...? oder ist dies bei amibroker offen sobald man "function" eingibt? eine "offene" deklarierung wäre ein vorteil.

 

Ich bin ja kein Programmierer, insofern weiß ich nicht genau, was eine "offene" Deklarierung ist. Aber void, double etc. gibt es bei AB nicht. Insofern finde ich auch AFL einfacher als in vielen anderen TA-Programmen wie z.B. Tradestation oder Wealthlab.

 

EDIT 13:31 oder ist amibroker so hinterher dass man dem programm noch sagen muss... hey dieser nachfolgender block ist eine funktion ... nee mal im ernst. hab gehört dass amibroker auf pascal basiert und das ist bei mir >15 jahre her

 

Definitiv nicht. AFL basiert auf C bzw. C++.

[duncan]

hallo ich kenne mich bei amibroker nicht aus aber sollte statt "function" nicht der wert des rückgabewertes dieser funktion deklariert sein? void, double, bool...? oder ist dies bei amibroker offen sobald man "function" eingibt? eine "offene" deklarierung wäre ein vorteil.

Hi, das ist völlig offen:Aus dem Handbuch:

User-definable functions, procedures. Local/global scope

User-definable functions allow to encapsulate user code into easy-to-use modules that can be user in many places without need to copy the same code over and over again.

 

Functions must have a definition. The function definition includes the function body — the code that executes when the function is called.

 

A function definition establishes the name, and attributes (or parameters) of a function. A function definition must precede the call to the function. The definition starts with function keyword then follows function name, opening parenthesis then optional list of arguments and closing parenthesis. Later comes function body enclosed in curly braces.

 

A function call passes execution control from the calling function to the called function. The arguments, if any, are passed by value to the called function. Execution of a return statement in the called function returns control and possibly a value to the calling function.

 

If the function does not consist of any return statement (does not return anything) then we call it a procedure.

 

Following is an example of function definition:

 

 

// the following function is 2nd order smoother

 

function IIR2( input, f0, f1, f2 )

{

result[ 0 ] = input[ 0 ];

result[ 1 ] = input[ 1 ];

 

for( i = 2; i

{

result[ i ] = f0 * input[ i ] +

f1 * result[ i - 1 ] +

f2 * result[ i - 2 ];

}

 

return result;

}

 

Plot( Close, "Price", colorBlack, styleCandle );

Plot( IIR2( Close, 0.2, 1.4, -0.6 ), "function example", colorRed );

Du musst nur an lokale und globale Variablen denken ...

Due to the fact that AFL does not require to declare variables the decision whenever given variable is treated as local or global is taken depends on where it is FIRST USED.

 

If given identifier appears first INSIDE function definition - then it is treated as LOCAL variable.

If given identifier appears first OUTSIDE function definition - then it is treated as GLOBAL variable.

 

This default behaviour can be however overriden using global and local keywords (introduced in 4.36) - see example 2.

 

Example (commentary):

 

k = 4; // this is GLOBAL variable

 

function f( x )

{

z = 3; // this is LOCAL variable

return z * x * k; // 'k' here references global variable k (first used above outside function)

}

 

z = 5; // this is GLOBAL variable with the same name as local variable in function f

Gruß Duncan

Edited August 2, 2009 by duncan

[oldschuren]

@siscop

So weit wie ich das gescheckt habe kommt void ect. bei Objektorientierter Programmierung vor. Das ist genau das warum ich mich nicht weiter mit java beschäftigt habe. Diese ganze Notation geht mir auf dem Sack... Das das auch anders gehen kann sieht man bei der ScriptSprache Ruby. Da kann man (wenn man will) objektorientiert Coden, ist aber vom Sprachgebrauch einer natürlichen Sprache angelehnt.

[Krümel]

So weit wie ich das gescheckt habe kommt void ect. bei Objektorientierter Programmierung vor.

Nee, generell bei typisierten Sprachen. Das hat mit OO erstmal nix zu tun ;).

Starke Typisierung

C und MQL zählen auch dazu.

 

 

Das ist genau das warum ich mich nicht weiter mit java beschäftigt habe. Diese ganze Notation geht mir auf dem Sack...

Java und C# und ähnliche objektorientierte Sprachen haben auch ihre Vorteile. V.a. wenn die Programme wirklich groß werden. Da wächst Dir das ganze lediglich funktionsbasierte Zeug dermaßen schnell über den Kopf... so schnell kannst Du gar nicht gucken .

 

In den letzten Jahren ist ja noch zusätzlich komponentenbasierte Programmierung dazu gekommen. Sprich: man verwendet fertige Bausteine wie Webbrowser u.ä., um sich eine Applikation zusammenzubauen/zu konfigurieren. Man muss ja nicht immer wieder erneut im Urschleim stochern. Das geht mit Java/C# extrem schnell und Zeit ist Geld ;).

 

Für kleine Programme wirkt objektorientierte Programmierung allerdings oft overdressed. Man denke nur an die dicken Main-Funktionen in Java o.ä., um einmal "Hello World" in die Konsole zu schreiben

 

Dafür sind die Sprachen und Konzepte aber auch nicht gedacht. Ich borg mir ja auch keinen Bagger im Baumarkt, um mal nen 2 mal 1 Meter Gemüsebeet umzugraben.

 

Ne Programmiersprache ist auch nur ein Werkzeug, um eine bestimmte Art/Klasse von Problemen möglichst gut zu lösen. Aber alle Probleme gleichermaßen gut lösen kann irgendwie keine. Deswegen lege ich mich z.B. auch nicht fest, sondern versuche, möglichst flexibel zu sein.

[siscop]

Nee, generell bei typisierten Sprachen. Das hat mit OO erstmal nix zu tun ;).

Starke Typisierung

Stark typisierte Sprachen (Keine der genannten Sprachen genügt allen Definitionen):

 

* Ada

* C# (solange die Option /unsafe nicht verwendet wird)

* Component Pascal (erfüllt alle oben angegebenen Kriterien, wenn das Modul SYSTEM nicht explizit importiert wird)

* D

* Haskell

* Java

* Python (keine Bindung zwischen Variable und Datentyp)

 

Schwach typisierte Sprachen:

 

* JavaScript

* Perl

* PHP

* C++

Perl und PHP ok... diese $variablen brauchen sowas nicht. war mir damals echt angenehm. ABER was sucht C++dort?

[Krümel]

Perl und PHP ok... diese $variablen brauchen sowas nicht. war mir damals echt angenehm. ABER was sucht C++dort?

Ich denke, C++ taucht deswegen auf, weil die Eigenschaften für starke Typisierung zum Großteil nicht erfüllt sind:

Eine Sprache ist stark typisiert, wenn

 

1. Datentypen an Variablennamen anstatt an diskrete Werte geknüpft sind - die passende Terminologie dafür wäre statische Typisierung (static typing) im Gegensatz zur dynamischen Typisierung (dynamic typing);

2. sie Typüberprüfungen zur Compile-Zeit enthält;

3. automatische oder implizite Typkonvertierungen verboten sind;

4. Typkonvertierungen explizit durchgeführt werden müssen;

5. die Sprache keine Mechanismen besitzt, um das Typ-System zu umgehen, etwa type casts (Typumwandlungen) in C;

6. es ein komplexes, fein abgestuftes System an Typen mit Sub-Typen gibt;

7. der Datentyp eines Objektes fix ist und sich während der gesamten Lebensdauer des Objektes nicht verändern kann (auch diese Eigenschaft wird oftmals statische Typisierung genannt);

8. das Typ-System das Laufzeitverhalten eines Programmes garantieren kann.

Quelle: http://de.wikipedia.org/wiki/Starke_Typisierung

 

So richtig kenn ich mich mit C++ auch nicht aus. Meine letzte Begegnung liegt ca. 5 Jahre zurück, da durfte ich noch unter Linux irgendwelche "verteilten Systeme" für CORBA schreiben für nen Seminarschein in Softwarekonstruktion und im Semester drauf unter Windows mit MFC meine erste größere Applikation überhaupt programmieren.

 

Ich vermute mal, es liegt u.a. an der Mehrfachvererbung in C++, wodurch die Eigenschaft verletzt ist, dass das Typ-System das Laufzeitverhalten eines Programmes garantieren kann.

Außerdem erinnere ich mich dunkel an wilde Typcastorgien. Das war aber auch das einzig Spaßige an C++ für mich. Ansonsten hab ich bislang für jedes Problem mindestens eine besser geeignete Programmiersprache gefunden, so dass C++ für mich recht entbehrlich ist.

 

Gerade für den Entwurf von Handelssystemen sind typisierte Sprache eher Ballast. Ich bevorzuge da auch eher Sprachen wie Equilla oder R.

[Technix]

Ausreichend vernünftig typisierte Sprachen bieten bei schon nur etwas größeren Programmen ab einigen hundert Zeilen bestimmt große Vorteile bezüglich der statischen Prüfbarkeit des Programm-Codes durch den Compiler. Ohne die Typisierung werden viele Fehler erst zur Laufzeit entdeckt. Darüber hinaus gibt es bei Sprachen ohne Typisierung meist sehr diffizile Fehler-Quellen durch die recht komplexen Regeln der Runtime-Typ-Umwandlung.

 

Ganz schlimme software-technologische Defizite haben Sprachen, wo Variablen überhaupt nicht explizit erklärt werden müssen und dann stillschweigend mit einem Standardwert (z. B. 0) weiterbenutzt werden. Da führen dann selbst simple Schreibfehler leicht zu langen Debugging-Orgien.

 

Bei der Bewertung einer Sprache muß nicht nur auf die Kürze des erstmaligen Hinschreibens geachtet werden, sondern vielmehr auf die Verständlichkeit und Sicherheit in der späteren Wartung, da sie in der Regel höhere Kosten erzeugt als die erstmalige Programm-Erstellung. Da ist dann jede Redundanz, die dem Compiler hilft, Fehler gleich bei der Übersetzung zu monieren, ein großer Gewinn.

 

Programmier-Anfänger freuen sich meistens schon, wenn ein Programm überhaupt in etwa das tut, was sie wollten, Profis und erst recht größere Team haben auch sehr genau die Gesamtkosten eines Projektes über seine gesamte Entwicklungs- und Nutzungzeit im Auge, da davon letztendlich die Profitabilität ihres Unternehmens abhängt. Die spätere Wartungs-Programmierung schneidet dabei in der Regel geradezu bösartig schlecht ab, weil für jede noch so kleine Änderung immer wieder eine ziemliche Zeit benötigt wird, sich in die Aufgabe hineinzufinden und viele Zusammenhänge, die nicht durch eine haarfeine Software-Technologie erzwungen werden, dabei auf die Schnelle sehr oft übersehen werden, wodurch bei der Wartung recht häufig neue Fehler eingebaut werden.