кои от двата варианта е по добар според вас и що?

functoin ReadData(){

 if(CanReadData){

  //read data here

 }

}



...

    ReadData(); //skrito e dali moze da se 4ete ili ne 

...



-- ili --



function ReadData(){

  //read data here

}

...

   if(CanReadData){// pokazvame 4e 4eteme samo ako moze

     ReadData();

   }

...


           


           

Ще се наложи да дадеш повече контекст . Особено частта, където се извиква четенето на данните.

Губи ми се else елемента -- кво става ако не можеш да четеш? Плющят изключения ли?

Аз лично обичам като викам код да не се грижа дали мога или не мога да чета. Бих предпочел скритото CanReadData допитване. Съответно бих искал при невъзможност за четене да ми се върне подходящ NullObject (виж гугъл за Null Object Pattern) или в най-лошия случай да се хвърли изключение.

--
"Agile is a mindset, not a set of practices, rules, or tools."
Tom Poppendieck

Както ти каза колегата, зависи от това къде и как ще се използва.

Ако викаш функцията на 100 места, трябва да напишеш на 100 места:


if(CanReadData){// pokazvame 4e 4eteme samo ako moze

ReadData();

}


Лично аз не бих го направил така.

Ами първият вариант е малко заблуждаващ ако някой друг програмист ти ползва кода с ауто-комплете, защото името подвежда ще данните ще бъдат прочетени на всяка цена - аз поне така тълкувам ReadData.

ReadData void ли е? Или хвърля exceptions?

Ако е void и не хвърля exception когато данните не са прочетени, вариант 1 става заблуждаващ, май.

Ако си на анси-с май там тенденцията е функциите да връщат error-code. На Жаба тенденцията е да се хвърлят exceptions. В .НЕТ стила май по-скоро клони към вторият вариант.

--
Increasing performance by lowering expectations.

В отговор на:

---

малко заблуждаващ ако някой друг програмист ти ползва кода с ауто-комплете

---

Хмм. Аз пък хич не мога да си ги представя нещата без autocomplete. Искам да кажа, че вината не е в autocomplete-a. Студиото си има много добър debug mode (от скоро го ползвам), който доста помага за отстраняване на грешки.
Просто трябва да се балансира:
autocomplete - debug mode - manual
От което и да се откажеш е излишно екстремно преживяване. Същото важи и за прекаляването, с което и да е от трите.

Кво ще кажеш за втория вариант (разделени) + още:

function ReadDataIfCan() {
if (CanReadData) {
ReadData();
}
}

кой, квото му трябва това си вика.

В отговор на:

---

много добър debug mode

---

Декоратор патърна е добро решение в случая. Е говоря за ОО и функционални езици. Иначе изглежда странно ;-> не искам да си го представям в процедурно C.

Примерно DataReader, който чете без да гледа дали може или не. CheckedReadingDecorator, може да работи с DataReader и да доставя проверката за грешки.

--
"Agile is a mindset, not a set of practices, rules, or tools."
Tom Poppendieck

Хм, не знам какъв е случая. На мен преди месеци ми мина през ръцете едно
парче код на C++ за code review.
Та там имаше метод от типа:
unsigned char XXX::GetByte()
{
if(...notEnougDataExpr...)
throw smth....;
return *buffer++;
}
Та аз го върнах с мнение, че на тази проверка мястото и не е вътре в метода.
Според дизайна, XXX::GetByte() трябваше да се вика за всеки байт, прочетен и кеширан от файл, опашка, канал или каквото и да е друго. Ставаше въпрос за повече от 1 блока данни с вероятна дължина - стотици хиляди байтове.
Ставаше въпрос за ОО решение и XXX::GetByte() беше вътршна и не се викаше от 100 места. Та моята препоръка беше, да се смени проверката с
assert, и с коментар, че ако не знаеш колко можеш да четеш, по-добре не чети.
Все пак ставаше въпрос за ключово място в кода и добавената проверка предполагам че умножава по 2 времето за изпълнение на тая функция.
Та - така. Но това беше моя случай - за случаия коментиран тук - не знам - не съм наясно, за какво става точно въпрос.