A feltételek meglehetősen összetettek lehetnek, és lehetnek „láncolt” feltételek is (logikai „és” vagy „vagy” operátorral összekapcsolva). Az OTRS kódolásakor tisztában kell lennie számos helyzettel.

A bevált Perl gyakorlatok azt mondják, hogy a magas precedenciájú operátorokat (&& és ||) nem kellene keverni az alacsony precedenciájú operátorokkal (and és or). A zűrzavar elkerülése érdekében mindig a magas precedenciájú operátorokat használjuk.

if ( $Condition1 && $Condition2 ) { ... }

# e helyett

if ( $Condition and $Condition2 ) { ... }
                    
                    

Ez azt jelenti, hogy tisztában kell lennie a buktatókkal. Néha zárójeleket kell használnia, hogy világossá tegye, mit szeretne.

Ha hosszú feltételei vannak (a sor 120 karakternél hosszabb), akkor több sorra kell tördelnie azt. Továbbá a feltételek kezdete egy új sorban van (nem az if sorában).

if (
    $Feltétel1
    && $Feltétel2
    )
{ ... }

# e helyett:

if ( $Feltétel1
    && $Feltétel2
    )
{ ... }
                    
                    

Jegyezze meg azt is, hogy a jobboldali zárójel egyedül áll a sorban, valamint a baloldali kapcsos zárójel szintén új sorban van, és ugyanolyan behúzással rendelkezik mint az if. Az operátorok egy új sor elején vannak! A következő példák bemutatják, hogyan kell ezt csinálni…

if (
    $XMLHash[0]->{otrs_stats}[1]{StatType}[1]{Content}
    && $XMLHash[0]->{otrs_stats}[1]{StatType}[1]{Content} eq 'static'
    )
{ ... }

if ( $TemplateName eq 'AgentTicketCustomer' ) {
    ...
}

if (
    ( $Param{Section} eq 'Xaxis' || $Param{Section} eq 'All' )
    && $StatData{StatType} eq 'dynamic'
    )
{ ... }

if (
    $Self->{TimeObject}->TimeStamp2SystemTime( String => $Cell->{TimeStop} )
    > $Self->{TimeObject}->TimeStamp2SystemTime(
        String => $ValueSeries{$Row}{$TimeStop}
    )
    || $Self->{TimeObject}->TimeStamp2SystemTime( String => $Cell->{TimeStart} )
    < $Self->{TimeObject}->TimeStamp2SystemTime(
        String => $ValueSeries{$Row}{$TimeStart}
    )
    )
{ ... }
                    
                    

Általánosan azért használunk „hátul álló if” utasításokat, hogy csökkentsük a szintek számát. De ne használjuk többsoros utasításoknál, és csak akkor megengedett, amikor visszatérési utasításokat hoz magával a függvény, vagy egy ciklus befejezéséhez, illetve a következő iterációra való ugráshoz.

Ez helyes:

next ITEM if !$ItemId;
                    
                    

Ez hibás:

return $Self->{LogObject}->Log(
    Priority => 'error',
    Message  => 'ItemID szükséges!',
) if !$ItemId;
                    
                    

Ez kevésbé karbantartható ennél:

if( !$ItemId ) {
    $Self->{LogObject}->Log( ... );
    return;
}
                    
                    

Ez helyes:

for my $Needed (1..10) {
    next if $Needed == 5;
    last  if $Needed == 9;
}
                    
                    

Ez hibás:

my $Var = 1 if $Something == 'Yes';
                    
                    

Ha több változója van, akkor deklarálhatja azokat egyetlen sorban, ha azok „összetartoznak”:

my ($Minute, $Hour, $Year);

                    

Egyébként tördelje azokat külön sorokba:

my $Minute;
my $ID;
                    
                    

Ne állítson be undef vagy '' kezdeti értéket a deklarációban, ugyanis ez elrejtheti a hibákat a kódban.

my $Variable = undef;

# ugyanaz mint

my $Variable;
                    
                    

Akkor állíthat be egy változót '' értékre, ha szövegeket szeretne összefűzni:

my $SqlStatement = '';
for my $Part ( @Parts ) {
    $SqlStatement .= $Part;
}
                    
                    

Egyébként „előkészítetlen” figyelmeztetést kaphat.

A szubrutinoknak átadott paraméterek lekéréséhez az OTRS normális esetben a %Param kivonatot használja (nem a %Params kivonatot). Ez jobban olvasható kódot eredményez, mivel minden esetben tudjuk, hogy amikor %Param kivonatot használjuk a szubrutin kódokban, akkor paraméterkivonat került átadásra a szubrutinnak.

Csak néhány kivételnél kell a paraméterek szabályos listáját használni. Így el szeretnénk kerülni az ehhez hasonlókat:

sub TestSub {
    my ( $Self, $Param1, $Param2 ) = @_;
}
                    
                    

Inkább ezt szeretnénk használni:

sub TestSub {
    my ( $Self, %Param ) = @_;
}
                    
                    

Ennek számos előnye van: nem kell megváltoztatnunk a kódot a szubrutinban, amikor egy új paramétert kell átadni, és egy elnevezett paraméterekkel rendelkező függvény hívása sokkal olvashatóbb.

Ha egy függvényhívás egynél több elnevezett paramétert igényel, akkor tördelje azokat több sorba:

    $Self->{LogObject}->Log(
        Priority => 'error',
        Message  => "Need $Needed!",
    );
                    

E helyett:

    $Self->{LogObject}->Log( Priority => 'error', Message  => "Need $Needed!", );
                    

A szubrutinoknak rendelkezniük kell egy return utasítással. Az explicit return utasítás előnyben részesített az implicit módszernél (az utolsó utasítás eredménye a szubrutinban), mivel ez tisztázza, hogy mit ad vissza a szubrutin.

sub TestSub {
    ...
    return; # undef visszaadása, de nem az utolsó utasítás eredménye
}
                    
                    

Az explicit visszatérési értékek azt jelentik, hogy nem kell egy return utasítást tenni egy szubrutinhívást követően.

return $Self->{DBObject}->Do( ... );
                    
                    

A következő példa jobb, mivel ez explicit módon megmondja, hogy mi kerül visszaadásra. A fenti példával az olvasó nem tudja, hogy mi a visszatérési érték, mivel nem tudhatja, hogy a Do() mit ad vissza.

return if !$Self->{DBObject}->Do( ... );
return 1;
                    
                    

Ha egy szubrutin eredményét hozzárendeli egy változóhoz, akkor egy „jó” változónév jelzi, hogy mi lett visszaadva:

my $SuccessfulInsert = $Self->{DBObject}->Do( ... );
return $SuccessfulInsert;
                    
                    

A use strict és use warnings utasításoknak kell az első két „use”-nak lennie a modulban. Ez helyes:

package Kernel::System::ITSMConfigItem::History;

use strict;
use warnings;

use Kernel::System::User;
use Kernel::System::Time;
                    
                    

Ez hibás:

package Kernel::System::ITSMConfigItem::History;

use Kernel::System::User;
use Kernel::System::Time;

use strict;
use warnings;
                    
                    

Az OTRS-ben sok objektum érhető el. De nem kell minden egyes objektumot használnia minden fájlban az előtétprogram/háttérprogram elválasztásának megtartásához.

A szubrutinokat mindig dokumentálni kell. A dokumentum tartalmaz egy általános leírást arról, hogy mit csinál a szubrutin, egy minta szubrutinhívást, és hogy mit ad vissza a szubrutin. Ezeknek ebben a sorrendben kell lenniük. Egy minta dokumentáció így néz ki:

=item LastTimeObjectChanged()

calculates the last time the object was changed. It returns a hash reference with
    information about the object and the time.

    my $Info = $Object->LastTimeObjectChanged(
        Param => 'Value',
    );

This returns something like:

    my $Info = {
        ConfigItemID    => 1234,
        HistoryType     => 'foo',
        LastTimeChanged => '08.10.2009',
    };

=cut
                    

Lemásolhat és beilleszthet egy Data::Dumper kimenetet a visszatérési értékekhez.