История изменений

При чтении тоже?

если в abstract-е статьи все 3 фразы будут без изменений взяты из основного текста статьи, ты тоже будешь недоволен?

это я к тому, что как раз таки такой подход помогает чтению

Плюс параметров может быть много (плохо ли это - другой вопрос), тогда даже их имена в одну сроку не влезут и с разделением смотреться будет ещё хуже.

именно в таком случае они смотреться будут лучше, так как объявление функции в одну строку таки влезет

плюс к этому — многие пишут доки на параметры, и там опять придется повторять его, а здесь — нет; как это может выглядеть:

do_something_interesting( parameter1, parameter2, parameter3 ) = void { // делает что-то такое этакое (сюда можно впихнуть и длинное описание)

    parameter1 = &%%\$%^('a) SomeClass(?); // тут описание параметра1 для доков 
    parameter2 = &%%\$%^('a) SomeClass(?); // тут описание параметра2 для доков 
    parameter3 = &%%\$%^('a) SomeClass(?); // тут описание параметра3 для доков 

    // тело функции

    really_do_something( parameter1+parameter2 ); 
    really_do_something( parameter3+3 ); 

}

&%%\$%^('a) это подколка, если че

кстати, часто исходя из названия параметров более-менее понятен их тип, так что читать

select_log_enties( start_time, end_time, criteria ) = array(String) {

можно не глядя вовнутрь

при этом тип возвращаемого значения важен, т.к.

select_log_enties( start_time, end_time, criteria ) = array(ParsedLogEntry) {

При чтении тоже?

если в abstract-е статьи все 3 фразы будут без изменений взяты из основного текста статьи, ты тоже будешь недоволен?

это я к тому, что как раз таки такой подход помогает чтению

Плюс параметров может быть много (плохо ли это - другой вопрос), тогда даже их имена в одну сроку не влезут и с разделением смотреться будет ещё хуже.

именно в таком случае они смотреться будут лучше, так как объявление функции в одну строку таки влезет

плюс к этому — многие пишут доки на параметры, и там опять придется повторять его, а здесь — нет; как это может выглядеть:

do_something_interesting( parameter1, parameter2, parameter3 ) = void { // делает что-то такое этакое (сюда можно впихнуть и длинное описание)

    parameter1 = &%%\$%^('a) SomeClass(?); // тут описание параметра1 для доков 
    parameter2 = &%%\$%^('a) SomeClass(?); // тут описание параметра2 для доков 
    parameter3 = &%%\$%^('a) SomeClass(?); // тут описание параметра3 для доков 

    // тело функции

    really_do_something( parameter1+parameter2 ); 
    really_do_something( parameter3+3 ); 

}

&%%\$%^('a) это подколка, если че

кстати, часто исходя из названия параметров более-менее понятен их тип, так что читать

select_log_enties( start_time, end_time, criteria ) = array(String) {

можно не глядя вовнутрь

при этом тип возвращаемого значения важен, т.к. select_log_enties( start_time, end_time, criteria ) = array(ParsedLogEntry) { это уже совсем другая функция

При чтении тоже?

если в abstract-е статьи все 3 фразы будут без изменений взяты из основного текста статьи, ты тоже будешь недоволен?

это я к тому, что как раз таки такой подход помогает чтению

Плюс параметров может быть много (плохо ли это - другой вопрос), тогда даже их имена в одну сроку не влезут и с разделением смотреться будет ещё хуже.

именно в таком случае они смотреться будут лучше, так как объявление функции в одну строку таки влезет

плюс к этому — многие пишут доки на параметры, и там опять придется повторять его, а здесь — нет; как это может выглядеть:

do_something_interesting( parameter1, parameter2, parameter3 ) = void { // делает что-то такое этакое (сюда можно впихнуть и длинное описание)

    parameter1 = &%%\$%^('a) SomeClass(?); // тут описание параметра1 для доков 
    parameter2 = &%%\$%^('a) SomeClass(?); // тут описание параметра2 для доков 
    parameter3 = &%%\$%^('a) SomeClass(?); // тут описание параметра3 для доков 

    // тело функции

    really_do_something( parameter1+parameter2 ); 
    really_do_something( parameter3+3 ); 

}

&%%\$%^('a) это подколка, если че

кстати, часто исходя из названия параметров более-менее понятен их тип, так что читать

select_log_enties( start_time, end_time, criteria ) = array(String) {

можно не глядя вовнутрь

При чтении тоже?

если в abstract-е статьи все 3 фразы будут без изменений взяты из основного текста статьи, ты тоже будешь недоволен?

это я к тому, что как раз таки такой подход помогает чтению

Плюс параметров может быть много (плохо ли это - другой вопрос), тогда даже их имена в одну сроку не влезут и с разделением смотреться будет ещё хуже.

именно в таком случае они смотреться будут лучше, так как объявление функции в одну строку таки влезет

плюс к этому — многие пишут доки на параметры, и там опять придется повторять его, а здесь — нет; как это может выглядеть:

do_something_interesting( parameter1, parameter2, parameter3 ) = void { // делает что-то такое этакое (сюда можно впихнуть и длинное описание)

    parameter1 = &%%\$%^('a) SomeClass(?); // тут описание параметра1 для доков 
    parameter2 = &%%\$%^('a) SomeClass(?); // тут описание параметра2 для доков 
    parameter3 = &%%\$%^('a) SomeClass(?); // тут описание параметра3 для доков 

    // тело функции

    really_do_something( parameter1+parameter2 ); 
    really_do_something( parameter3+3 ); 

}

&%%\$%^('a) это подколка, если че