Parameters (computer science)

Parameters - also called transfer values (in German) - are variables in computer science by means of which a computer program (often a subroutine ) can be "set" to process certain values. Parameters are therefore influencing factors set outside the program ; they are used in particular when calling subroutines to 'tell' them which data / values ​​they should process and, if necessary, how.

By means of parameterization, programs can be made more flexible in their application without the program having to be recreated. The values ​​that can be set must be specified when creating programs. Parameters can e.g. For example, certain limit values ​​/ selection conditions (for amounts, a date or the like) or texts to be used or also control the "what" and "how" of the processing (e.g. carry out check X - yes / no).

A distinction is made between “formal parameters” (= as part of the function definition in the program code; example:) <Funktionsname>( <Par1>, <Par2>, ..) and “actual parameters” , also called “arguments” (= the respective value for Par1or Par2for individual function calls).

If an argument is not passed for each parameter when the (sub) program is called, this can use a standard assumption made when the program was created or (depending on the implementation) the processing can be canceled due to missing parameters.

Purpose of parameters

Principle of parameterization

• Parameterization is an aspect of software architecture : Sun implemented software can the quality criteria for software to 9126 ISO / IEC , particularly in the points adaptability and modifiability match, but also supports the requirements interchangeability , usability and others.
• Through parameterization, program changes can be avoided for situations that can be expected in advance, thus minimizing effort and the risk of errors (through program changes).
• Parameterization is an indispensable requirement for program use in many different environments ( multi-client capability ). It is therefore generally practiced very comprehensively, especially with system programs (at least using configuration parameters ).
• In modular programming , the interfaces between the individual modules are implementation-immanent parameters. They are part of the signature of functions , methods and procedures and thus an essential communication medium between the calling program and the called subroutine . Information can flow in both directions.
• In a broader sense, macros are also subroutines: the programmer defines parameters for them in the source code and thus determines the processing details for the macro.

From the point of view of the system concept , parameters are input data ; however, they differ from normal input data e.g. B. as follows:

• Parameter data are not part of the actual processing purpose of the program, but rather - as far as this was taken into account during implementation - they should set the program to individual values ​​/ information and / or possible processing variants.
• Parameter data are usually one-dimensional, i.e. In other words, there are no sets of objects (such as in a customer or product file), but mostly only the information pertaining to a specific situation, often only in the form of a single data field .
• As a rule, they are not simply read by the program like other files , but are often interpreted using special mechanisms (of the operating system or the programming language ), especially when used as subprogram parameters.
• Except for subroutines, they are usually specified by the user , user or operator of computers responsible for the technical process of the program , e.g. B. employees of the data center, and in these cases often remain unchanged over a long period of time.

Different parameter terms

Parameters are used in various functions in computer science:

• as an installation parameter when installing software
• as configuration parameters that control the behavior of the software
• as runtime parameters in order to be able to influence the software at runtime.
• as an interface between calling programs and called subroutines; see below.

When using several parameters, it is important to be able to identify and differentiate between the individual parameters. There are two detection methods for this:

Positional parameters

are assigned at handover based on their position. Example: The third parameter is the start time. If the parameter values ​​do not have a fixed length, position parameters must be separated by a separator . The separator is e.g. B. the semicolon (see CSV file ) or the vertical line are used. Arguments that are not to be specified are usually only identified by their separator, which leads to strings like 300;ABC;;;XYZ(third and fourth parameters not used).

Keyword parameters

are marked with a unique keyword when they are handed over and can therefore be identified regardless of their position. Example: startzeit=13:30. A separator is also required for keyword parameters.

Keyword parameters usually differ from positional parameters in that they can also be omitted.

Whether empty parameters are allowed and how to handle them, e.g. B. empty character string or standard assumption (English default argument ) is to be handled by the program. The format in which they are to be specified must also be specified / agreed for both variants ; in the example: "hh: mm", 2 digits each, separated by a colon.

Furthermore, parameters can be distinguished according to:

Source of the parameters

Internal = effective from program to (sub) program; External = from outside, e.g. B. parameters set by the user

Stability / frequency of change

Is the parameter set frequently or almost always , or is it rarely changed ?

Type / type of parameters

Variables such as amount fields (e.g. limit values), time information (current date), text constants and so on, or functional instructions such as "Y / N" or similar (for 'only list incorrect data', 'only log, do not save') )

Direction of information flow

Call parameters (in the direction of the program / subroutine) or return parameters (in the direction of the calling program; only for subroutines); also bidirectionally is possible (call / return)

Examples of parameters

• VAT rates in percent (for business applications)
• Should only total or individual lines be output in lists? (controls the level of detail of user media)
• Name of the software owner (currently with multi-client capability , visible in the form headers)
• Loan amount, interest rate, repayment amount, repayment period (to calculate a repayment schedule )
• Account number as a call parameter to the subroutine 'check digit calculation', check digit as return value

In the broadest sense, computer commands (in all programming languages and also in machine language ) are parameters: They contain a function code plus addresses, lengths and so on for the data to be processed. The information is interpreted and decoded by the computer's control unit and executed accordingly.

A concrete example for the application of parameters:

As part of an application for managing invoices, a program is to be created that outputs invoices for users in a list. As a technical requirement, it was determined that this list shows all invoices that have not yet been paid and that are older than 1 month, calculated at the time of the program run.

• Without parameterization the program would process:

Read bills; only process invoices with status = "open" and invoice date <(today ./. 1 month)

• An identical solution with parameters could provide the parameters "Invoice date older than", "Open_YN".

The program would have to check the parameters after starting and, if necessary, edit them for use. In the actual processing, no constants or fixed-coded commands (as before) would be used, but the set parameter values.

• This would give the user the following additional options:

The age of the invoice could be determined variably; the list could also show completed invoices or all invoices regardless of status.

• Going further could e.g. For example, the parameter "from amount = X" can be provided or the definition of whether only invoices with higher or only invoices with lower invoice amounts than X or all invoices are to be listed regardless of the amount. Invoices with small amounts could be B. excluded or requested in a separate list.
• Depending on the database system used, certain parameters can already be set in the read command for the invoice data, so that the DBMS only provides the corresponding invoices. Alternatively, the program would have to make the selection itself after reading it.

Media for parameter transfer

• If the program is a subroutine , the (or several parameters) are formally specified when it is defined (formal parameters) and (by the main program) are set to a specific value (actual parameter) when the subroutine is called for exactly one call.
• Command line parameters are passed in the call command , usually after the code for the function to be executed. Example: RENAME <old file name, new file name>. This category also includes the parameters used in program calls a Job Control Language (for mainframe programs . Eg OPC are) in the instructions set z. B. the current date.
• Parameters can also be contained in special parameter files. In this case, their content is interpreted by a control component of the program at the time of execution, if necessary when the program starts. Examples of this are entries in so-called registration databases (usually used for utility programs ), but also in operational or task-specific databases , files or table management systems.

Depending on the medium parameters with different methods detected , external parameters often using standard or custom editors . If this is provided for in the program, parameters for dialog programs can be entered by the user directly via the screen and keyboard .

Parameters in subroutines

Parameters are of essential importance in connection with the use of subroutines. These process data and return values ​​that mostly belong to the programs calling them. In order to inform a subroutine (which basically does not 'know' the data of the calling program) the subset of data that it has to process, certain techniques are used when calling the subroutine, which are mapped in high-level programming languages using a so-called formal parameter list . This expression was already used in the 1960s for the language ALGOL , which was then used as a teaching example, and is still used today. The terms parameter or argument are often used synonymously in this context, whereby "parameter" strictly speaking refers to the function definition, "argument" on the other hand to the actual call. When the subroutines are called via the actual parameter list (more precisely: argument list), certain values ​​are transferred with which they can work. The subroutines usually return return values .

All of the values ​​mentioned can also be references , pointers or addresses to memory areas. The terms mentioned are also synonymous. In C ++ jargon, however, a strict distinction is often made between reference and pointer . Reference is used to Type&denote the variant declared with , and pointers to Type*. The difference is that, unlike a pointer, a reference cannot be uninitialized or empty. This means that when a reference is used, a valid object of the corresponding type must always be transferred. References to basic data types are also allowed (e.g. int&).

Transfer of parameters / arguments

Depending on the computer architecture and the programming language, different procedures and conventions are used to transfer parameters from the calling to the software part to be called. For example, the parameters can be transferred via registers , whereby registers (numbers) determined by conventions point to an address list (which contains the addresses of the parameters / arguments), one register contains the entry address in the subroutine, another the return address. For details, see object modules for mainframes .

Transfer via the stack

A stack mechanism is used for this in other system environments . In these cases, the following basic knowledge is required to understand how subroutines work:

Basically, the memory of processors is divided into

• Program memory: This is where the machine code is located, which is processed as commands.
• Dynamic memory ( heap ): Data is stored there.
• Stack memory ( stack , call stack ): This is a special data area whose use is particularly important for subroutines.

Each thread has its own stack. In this are saved:

• The return addresses for continuing the program processing after the subroutine has been processed
• The actual parameters
• All data that are agreed locally in a procedure
• Return values

During program processing, the stack is addressed in the machine code using a special address register, the stack pointer or stack pointer . This always addresses the lower end of the memory area used as a stack. In addition, there is usually a base pointer that addresses a base address of the variables and actual parameters within the stack. The term stack can be translated as “stack” in German, and the term “stack storage” is also used. Information is stacked in the stack and stored and read out again according to the Last In - First Out (LIFO) principle . However, any address within the stack can also be accessed.

The parameters are transferred via the stack. Each actual parameter is placed on the stack in the order in which it is processed, usually from left to right (according to a strictly defined calling convention ). If necessary, this is converted to the format required by the subroutine.

When the subroutine is called, the so-called base pointer is then set to the address of the stack that has now been reached. This means that the parameters of the subroutine can be accessed relatively via the address stored in the base pointer , even if the stack is used for further storage.

Values ​​or references / pointers as parameters

If not only elementary data types such as intor floatare specified in the actual parameter list, but complete data structures , then usually not the values ​​of the data structure itself, but references (addresses) to the data structures are transferred in the stack. However, this depends on the call and the design of the actual parameter list. The following relationships apply in C and C ++:

void function(type* data)         // Funktionskopf, formale Parameterliste
…
struct { int a, float b } data;   // Datendefinition
function(&data);                  // Funktionsaufruf, tatsächliche Parameterliste

In this case, when the call is made, the address of the data is explicitly specified, expressed using the &as the referencing operator. When you call is dataa pointer (english pointer ) to the data. In general terms, reference to the data can be used.

The call function(data)without the referencing operator &leads to a syntax error. In C, however, only if the prototype of the called function is known.

In C ++, the function header can also be void function(type& data)written in the same example . Then the call is to function(data)be shaped. Based on the function prototype, which is necessarily known in C ++, the translator automatically recognizes that the function expects a reference according to the formal parameter list and compiles the storage of the address of the data on the stack in the machine code. This relieves the programmer of mental work, the call is easier. However, when it is called, it is not clear whether the data itself ( call by value ) or the address of the data is being transferred.

In C or C ++ it is also possible to program a transfer of values ​​instead of the usually sensible and common transfer of references. It looks like this:

void function(type data)          // Funktionskopf, formale Parameterliste
…
struct { int a, float b } data;   // Datendefinition
function(data);                   // Funktionsaufruf, tatsächliche Parameterliste

When called, the entire content of the structure is copied to the stack. That can be a lot if the structure is extensive. This can lead to a crash of the entire process if the stack limits are exceeded and this is not recognized in the runtime environment. A value transfer is useful in the following cases:

• Handover of a small structure
• Taking into account the fact that the content of the original structure is changed during processing. The content of the structure at the caller remains unchanged because a copy of the data is created and transferred.

Writing back via referenced data

In many programming languages, results can also be written back using references that were passed as parameters of the subroutine, for example in C and C ++:

void function(Type* data)
{
  data->a = data->b * 2;          // Wert in data->a wird veraendert.
}

This also applies to Java. The writing back can be unwanted because side effects should be prevented. A subroutine should process the values ​​of certain data structures in a read-only manner and should have no effect on them. In C ++ (or in C) it is possible to formulate:

void function(Type const* data)
{
  data->a = data->b * 2;          // Hier meldet der Übersetzer einen Syntaxfehler.
}

The notation used here with the keyword constshould make it clear that the indicated (referenced) area is to be regarded as constant. Possibly const Type*what is written is what is syntactically and semantically identical. Only in this case is it possible to transfer a memory area declared as constant at all. The construction

const struct Type { int a, float b } data = { 5, 27.2 };
function(Type* data) { … }        // Funktionsdefinition
function(&data);                  // Aufruf

leads to a syntax error in C ++ because it is not permitted to pass data designated as constant to a non-constant reference. In C, pointer types are not tested as precisely, so this example - depending on the translator used - might just trigger a warning in such cases.

However, in C and C ++ it is possible to change the type of the pointer within the function and then still have write access to the memory area. Such programming should only be used in special cases and should be appropriately documented externally.

In Java, there is no option of constmarking in a reference parameter to differentiate between write and non-write access to an instance. Instead, the concept provides for access protection using privateencapsulation. In particular, specific interface references can be used. With this method it is possible to control from the outside what a subroutine can change in the transferred data without knowing the subroutine in detail.

In object-oriented programming in Java and C ++, the reference to the class thisdata is passed implicitly with the pointer. It is therefore always possible to write to your own data for class methods.

Implementation at machine level

The concept of the stack was already explained above in the section Transfer via the stack .

For subroutines at the machine language level (assembler) it does not really matter, or it is up to the programmer how he manages the parameter transfer and the return address. It is also possible to transfer and save only in processor registers. However, when managing the return address, the necessity of a nested call of several (typically different) subroutines within one another must be taken into account. A restriction to a few or just one level only makes sense for very simple tasks. However, there are actually such concepts for tailored processors and tasks.

• The return address, that is the following address after calling the subroutines for the continuation of the calling program, is placed on the stack.
• The call parameters are first placed on the stack.
• Any necessary memory space for return values ​​is reserved on the stack beforehand, if necessary.
• The base pointer is placed on the stack.
• The subroutine is then called, that is, the command counter is changed to the start address of the subroutine.
• At the beginning of the subroutine, the base pointer is set to the value of the stack pointer as an address reference for the position of the parameters, the return jump and the local variables.
• The stack pointer is further decremented if the subroutine requires local variables. These are on the stack.
• At the end of the subroutine, the original value of the base pointer is fetched from the stack and thus restored.
• Then the return address is fetched from the stack and the instruction pointer is restored with it.
• The stack pointer is incremented by the value by which it was previously decremented.
• The calling program is thus continued.

In assembler you have to program all these things yourself. In the programming languages ​​C ++ and C, this is done by the translator. In Java, the same thing happens within the memory areas of the virtual machine, organized by the bytecode (generated by the Java translator) and the machine code in the virtual machine.

As an illustration, the generated assembler code ( 80x86 assembler) of the following simple function is shown:

float parabel(float x)
{
    return x * x;
}

Microsoft Visual Studio 6 on a PC was used as the compiler . The assembler code is visible in this IDE , for example when debugging at the machine level, but also when listing files are generated with the appropriate compiler options.

Machine code for the call: float y = parabel(2.0F);

  push        40000000h           ; Der Wert 2.0 wird in den Stack gelegt.
  call        parabel             ; Aufruf des Unterprogramms;
                                  ; call legt den Instructionpointer in den Stack
  add         esp, 4              ; Addieren von 4, das ist Byteanzahl des Parameters
  fst         dword ptr [ebp - 4] ; Abspeichern des Ergebnisses in y

Machine code of the subroutine:

parabel:
  push        ebp                 ; Der Basepointer wird im Stack gespeichert.
  mov         ebp, esp            ; Der Basepointer wird mit dem Wert des Stackpointer geladen.
  sub         esp, 40h            ; 64 Byte Stack werden reserviert.
  push        ebx                 ; CPU-Register, die hier verwendet = geändert werden,
  push        esi                 ; werden im Stack zwischengespeichert.
  push        edi
  fld         dword ptr [ebp + 8] ; Der Wert des Parameters x wird relativ zum Basepointer geladen
  fmul        dword ptr [ebp + 8] ; und in der floating-point-unit mit selbigem multipliziert.

  pop         edi                 ; Register werden restauriert.
  pop         esi
  pop         ebx
  mov         esp, ebp            ; Der Stackpointer wird genau auf den Stand wie beim Aufruf
                                  ; des Unterprogramms gebracht.
  pop         ebp                 ; Der Basepointer wird aus dem Stack restauriert.
  ret                             ; Der Instruction pointer wird aus dem Stack restauriert
                                  ; und damit wird nach dem call (oben) fortgesetzt.

The following example shows a handwritten assembler code for the signal processor ADSP-216x from Analog Devices for the following function to be called from C:

float set_floatExtend(_floatExtend* dst, float nVal);

This is a function that is supposed to save a nValvalue in the address dst. The special feature here is that the floating point value comprises 40 bits and must be divided between two 32-bit memory addresses.

 .GLOBAL _set_floatExtend;     ; Sprunglabel global sichtbar
 _set_floatExtend:             ; Sprunglabel angeben, das ist der Name des Unterprogramms,
                               ; aus C ohne Unterstrich anzugeben.
   I4 = R4;                    ; Im Register R4 wird der erste Parameter _floatExtend* dst übergeben.
                               ; Da es eine Adresse ist, wird diese in das Adressregister I4 umgeladen.
   PX = F8;                    ; Der zweite Parameter float nVal wird aus F8 in das Register PX geladen.
   dm(0,I4) = PX1;             ; Ein Teil des Inhaltes von PX, in PX1 sichtbar, wird auf
                               ; der Adresse gespeichert, die von I4 gezeigert wird.
   dm(1,I4) = PX2;             ; Speicherung des zweiten Teils auf der Folgeadresse
 ! FUNCTION EPILOGUE:          ; Standard-Abschluss des Unterprogramms:
   i12 = dm(-1,i6);            ; Das Adressregister i12 wird aus einer Adresse relativ zum Basepointer
                               ; (hier i6) geladen. Das ist die Rücksprungadresse.
   jump (m14,i12) (DB)         ; Das ist der Rücksprung unter Nutzung des Registers i12.
   F0 = F8;                    ; nach dem Rücksprung werden die noch im cashe stehenden Befehl verarbeitet,
                               ; hier wird der Wert in F8 nach dem Register R0 geladen, für return.
   RFRAME;                     ; dieser Befehl korrigiert den Basepointer i6 und Stackpointer i7.

Definition and technical application of subroutine parameters

Formal parameters

The formal parameters of a subroutine are usually specified after the name of the subroutine when it is declared or defined. These can be used in the subprogram, for example, without specific values ​​being known. Often only the data types of the formal parameters need to be specified in a declaration . The parameters used must always be assignment compatible with these formal definitions.

Example: Subroutine declaration in the programming languages ​​PASCAL and Delphi with x and y as formal parameters:

 FUNCTION Radius(x, y : REAL) : REAL;
 BEGIN
  Radius := SQRT((x * x) + (y * y))
 END;

The formal parameters, here xand y, are placeholders for the arguments or actual parameters to be passed each time they are used.

Actual parameters or arguments

To use the subroutine, it is called with actual parameters (arguments) that influence execution; these define the initial concrete value of the abstract formal parameters for this implementation. In order to better distinguish between formal parameters, the term argument has also been established for actual parameters , especially in descriptions of programming languages. In German you can also find the designation of current parameters , due to the incorrect translation of the English expression actual parameter (actual parameter). The type of transfer differs from programming language to programming language. The Fortran language uses fixed memory addresses for each subprogram during translation. Languages ​​like Pascal or C use the stack or processor register to pass parameters.

Example: Calling the subroutine with various actual parameters:

 r1 := Radius(x1, y1);               -- tatsächliche Parameter x := x1 und y := y1
 Durchmesser := 2 * Radius(13, -2);  -- tatsächliche Parameter x := 13 und y := -2

In short: (formal) parameters provide named storage space, similar to algebraic variables, arguments or actual parameters are concrete values ​​(or data objects) that are stored there and used accordingly.

Type hinting

If the data types of the formal parameters are specified, as in the above example, one speaks of type hinting . Type hinting is mandatory in many programming languages ​​( C , C ++ , Java and some more) (omitting it leads to a syntax error ), while scripting languages often do not offer the possibility of using type hinting.

• An example from C or C ++ :

 float radius (float x, float y);

• An example from PHP without type hinting:

 function radius($x, $y);

• An example from PHP with type hinting:

 /* Der erste Parameter muss vom Typ der Klasse PDO sein, andernfalls wird ein Fehler erzeugt */
 function getData(PDO $db, $y);

Replace the formal with actual parameters

There are different methods of replacing the formal parameters with the actual parameters during the parameter transfer:

1. With value parameters ( call by value ) the value of an expression is calculated and, if necessary, a copy of the result is created. This is used in place of the formal parameter. The actual parameters can be any expressions such as or . Any changes to the parameters in the subroutine are only made in the copy and are lost when the subroutine is completed. Large data structures such as fields are copied upon transfer, which can be undesirable. ${\displaystyle 2*x+1}$ ${\displaystyle sin(x)}$
2. Reference parameters ( call by reference ) pass a reference (usually the memory address) of the actual parameter. This is usually very quick. Changes remain in effect even after the subroutine is completed. Actual parameters can only be expressions whose address can be calculated, e.g. B. no constants.
3. Name parameters ( call by name ) insert the name of the actual parameter in place of the formal parameter. This can also happen several times. Together with the actual parameter, an environment is transferred that specifies the bindings of the free variables that occur in the actual parameter. The difference to value parameters is that the expression is calculated every time the parameter is used in the called function.

In a macro, the formal parameter is textually replaced by the actual parameter. The difference to name parameters is that naming conflicts are accepted. If there is a variable in an actual parameter that has the same name as a local variable, the local variable is used for macro expansion.

1. Value result parameters ( call by value / return or call by value and result ), like value parameters, initially generate a copy of the actual parameter when called. However, when the subroutine ends, the content of the parameter is written back. This parameter transfer mechanism can have a different effect on concurrent programs than the use of reference parameters, since another thread can access the variable in the calling procedure while the subroutine is being executed.
2. Result parameters ( call by result ) create a locally valid, uninitialized variable as a parameter. A value is assigned to this variable during processing of the subroutine and copied to the memory position of the call parameter at the end of the subroutine so that it is overwritten.
3. Call-by-need is a variant of name parameters in which each actual parameter transferred is evaluated a maximum of once. If an actual parameter is evaluated, all occurrences of the formal parameter are replaced by the value obtained. In Haskell , call-by-need is part of the lazy evaluation.

Modern, procedural programming languages ​​usually support value parameters and reference parameters, sometimes also value result parameters.

Example of various parameter transfers

 proc test(x,y)
 {
     y = y + 1;
     x = 10 * x;
 }

 a = 5;
 b = 4;
 test(a, b);
 print(a, b);
 test(b, b);
 print(b);

Output for value parameters ( call by value )

 5 4
 4

Explanation: The calls to testdo not change the variables a and b, so that the variables retain their original value after the subroutine has ended.

Output for reference parameters ( call by reference )

 50 5
 60

Explanation: When calling testin line 9, x receives the reference to a and y the reference to b. During processing, y is first increased by 1. Since b and y refer to the same address, b now has the value 5. In the next line, x is multiplied by 10, so a now has the value 50.

In the second processing of test, called in line 11, both x and y refer to b, since b was specified for both parameters. Therefore, all changes made testto x and y are made in the same memory area. y had the value 5 before this call, is increased by 1 in line 3 and then this value is multiplied by 10 in line 4; So the value 60 is now at the memory location. Back in the main program, b then points to the address at which the 60 that has just been calculated is, so 60 is output in line 12 for b.

Output for value result parameters ( call by value and result )

 50 5
 6 ''oder'' 50

Explanation: The second call to testcreates two copies of b, to which x and y point within test. When the subroutine is terminated, x has the value 50, y has the value 6. Depending on which value is saved back to the original b first, the result may vary.

Command line parameters

In addition, with many common programs for all common operating systems there is the option of passing parameters in the command line , which are then processed when called.

Example: Fictitious program call via the command line under Windows

 programm.exe -parameter -weiterer -xyz=(a|b) /usw

This would call up program.exe with the parameters “parameter”, “further”, “xyz = (a | b)” and “etc.”. Parameters are used with or without a value, whereby the value is appended to the name with a space , with special characters such as "=" or not delimited at all. Depending on which program is used, different parameters are available; Depending on the program, parameters with the same name generally have different effects. The formal rules for information also depend on the program; The fact that several different separators are used, as in the example, is unusual and only serves as a demonstration, but many programs offer flexible options.

Under Unix-like systems, parameters are traditionally specified with single letters and introduced with "-" if they are options or switches that can be selected from a set fixed for the respective program; on the other hand, parameters are not specially introduced when dealing with file names and similar free specifications. The demarcation from one another is done, if necessary, by white space. Example: “ls -l -t / usr / bin / usr / local / bin” or equivalent “ls -lt / usr / bin / usr / local / bin”. For programs that accept both single-letter and multi-letter options, the latter must be introduced with "-".

Under DOS (in the tradition of OpenVMS ), “/” is traditionally used in place of the “-” and values ​​of parameter names are separated with “=”. Both styles can be found on Windows.

In general, it can be said that experienced users often get results faster when using command line parameters than using other operating options, such as dialog windows in a GUI . With IrfanView, for example, it is easy to load any number of images using three parameters, convert them and save them in a different format .

See also

• Quality criteria for software according to ISO / IEC 9126
• Similar meanings of parameter

Individual evidence

1. ↑ British Standards Institute (ed.): The C Standard - Incorporating TC1 - BS ISO / IEC 9899: 1999 . John Wiley & Sons, 2003, ISBN 0-470-84573-2 , 3.1.
2. ^ Working Draft, Standard for Programming Language C ++. (PDF; 4.6 MB) Retrieved September 26, 2010 (English, Section 1.3.1).