String.IsNullOrEmpty

Гениално - в .НЕТ 2.0 най-накрая ще има нещото, което винаги съм се чудил защо не съществура досега:

String.IsNullOrEmpty

Явно не съм единствения в целият свят, който си пише стринговите пропертита по този начин:

public string Company
{
get
{
return (_company != null) ? _company : String.Empty;
}
set
{
_company = value;
}
}

Сега остава само и .НЕТ 2.0 да почне да се ползва преди 2010.

Не разбрах -- сега си спокоен и ще си пишеш пропертитата с директно връщане:

get
{
return _company;
}

И после ще питаш if ( String.IsNullOrEmpty( myObj.Company ) ) ?

Пак не ми изглежда добре .

А защо трябва да чакаме новия .НЕТ за това? Какво пречи get на пропертито да връща:
MyStringUtilClass.EmptyIfNull( _company );

?

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

>>Какво пречи get на пропертито да връща:
>>MyStringUtilClass.EmptyIfNull( _company );

Ами аз това и правя по принцип, макар че не ползвам (статичен?) метод MyStringUtilClass.EmptyIfNull за това, а си го пиша директно условно в getter-a на пропертито. Мислиш ли че подобно нещо е ок за рефакторинг (extract method предполагам?)

Както и да е, доброто на String.IsNullOrEmpty е, че се разбрали че това е проблем - на хиляди места съм виждал пособен код

if (stringInstance != null && stringInstance != string.Empty)
{
...
}

Докато всъщност това, което на мене лично ми трябва е нещо от сорта на strongly typed enums - примерно както има BorderColor.NotSet, така и да има String.NotSet, който да включва едновременно null & Empty проверка, за да може горе долу да се форсира изравняване на стила на писане в .НЕТ като цяло - защото аз хубаво ще го рефакторна моя код, ама като цяло щом всички пишат така пак е кофти.

В отговор на:

---

пиша директно условно в getter-a на пропертито. Мислиш ли че подобно нещо е ок за рефакторинг (extract method предполагам?)

---

Виж самата конструкция:
_company != null ? _company : String.Empty

_company се споменава два пъти. Логично е да издърпаме дупликацията с ExtractMethod. Същото можем да кажем за for ( int i = 0; i < myCount; i++ ), където i се повтаря 3 пъти! Е тези неща са си дефекти на езика, може и да не се тормозим чак толкова, че да ги оправяме.

Иначе би било супер ако имаше foreach идиом, който да дава и индекса от колекцията (когато има смисъл, разбира се). Нещо като foreach ( (index, value ) in myObjects ).


За кода:

if (stringInstance != null && stringInstance != string.Empty)
{
...
}

съм съгласен -- смърди от километри, не само заради дупликацията на stringInstance, ами и заради липсата на идея какво си очаквал да получиш от кода дето ти е върнал въпросния низ.

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

В отговор на:
--------------------------------------------------------------------------------

Същото можем да кажем за for ( int i = 0; i < myCount; i++ ), където i се
повтаря 3 пъти!

--------------------------------------------------------------------------------

И какво излиза - да не ползваме for цикли?

с малко влакче композирам патките в реката

пишеш на С++ и с for_each :)

Ами не точно. foreach циклите добре се справят в повечето случаи. Просто почти съм готов да твърдя, че прекомерната употреба на for циклите е design smell. Същото важи за два други мои недолюбвани оператора if и switch.

Почвам да си мисля, че в една добре проектирана обектна среда оператори като if, for, switch са ненужни. Който е виждал Ruby, Smalltalk, lisp ще разбере какво се опитвам да кажа.

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

Ами по принцип доста по-добре е да не се допускат недомислия във АПИ-то, а не после да се мислят "хакове" и бест-практисес как да се справяме с тези недомислия.

Проблемът всъщност въобще не е със доста объркващите проверки едновременно и за null и за string.Empty, a всъщност с това, че string като тип трябва да е value type.

Следното нещо в .НЕТ е невалидно:
int a = null;

Защо тогава:
string s = null;
е валидно?

И именно това, че стринг може да е нул води да всичките тези обърквания, за които ти говоря и са наложили доста грозния (действително както каза ти) хак String.IsNullOrEmpty.

Проблемът е, че толкова много хора нулват стринговете в своите програми, че заради backword compatibility превръщането на стринг във value type означава почти нулева background compatibility и пичовете просто не могат да го направят, но с това String.IsNullOrEmpty де факто си признават, че са объркали.

Вече специално във .НЕТ стринг няма да може да е value type в следващите 50 години предполагам и ще продължаваме да гледаме грозен код заради това.

--
Increasing performance by lowering expectations.

В отговор на:

---

Вече специално във .НЕТ стринг няма да може да е value type в следващите 50 години предполагам и ще продължаваме да гледаме грозен код заради това.

---

И това е така щото там около 1970-та година Кърниган и Ричи като са измислили C не са му сложили вграден тип за символен низ. А това пък е било щото някой преди това е решил нещо подобно в предходен език... Строуструп не е сложил низ в C++, Гослинг объркал нещата в Джава със java.lang.String класа, Хейлсберг решил да не губи масата дебелопери и да направи подобно нещо. Порочен кръг а .

Вижуъл бейсик 6 как си има вграден тип за символен низ, който да не може да е null (Set myString = Nothing ти казва Error 13 -- Type Mismatch). В това отношение ВБ.НЕТ е направил крачка назад.

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

С помощта на псевдонимите (не могат да са null) проверката за празен низ
става точно str.empty(). Семантиката е като на value type (не се замесват гадните pointers), предаването на параметри всъщност е чрез адрес и всичко е ок.

Следва мрънкане!

Аз се сещам за страшно много класове за низове: std::string, std::wstring, CString(MFC, VC++ 6.0), CString(WTL), CString(VS.NET), wxString(wxWidgets), Qt и Borland сигурно също имат техни QString и TString. За кой от тях говориш? Допускам std::string или std::wstring, защото те имат метод empty(), но може и да греша.

Всъщност адски ме дразни глупавата мода всеки да си дефинира собствен низ в C++. Не знам защо се прави това нещо -- може би е наследство отпреди стандарта от 98-ма година? Някой да знае кога низовите класове std::string и std::wstring са влезли в стандартната библиотека?

Да не говорим, че въпреки огромния избор от низови класове, куцо и сакато бичи с указатели char* и ръчно "управлява" паметта, защото на това са го научили в университета или някоя глупава книга. Мъка, мъка...

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

имах предвид. Модата всяка библиотека да си дефинира стринг и мен много
ме дразни и винаги когато имам избор използвам стандартния. Пък за char * важи приказката 'Навикът е втора природа'.

Ако се пробваш да форматираш малко числа с std::string бързо ще се откажеш в полза на sprintf, въпреки опастността да замажеш памет. От там отиваме на CString.Format, в която правят чудеса от храброст по тоя повод (от времето преди да има _snprintf)

Сега очаквам народът да каже - 'ползвай boost' - е да ама не е стандартен и може да не искам да го ползвам :)

stringstreams. Не съм срещал по-яка идея, свързана с форматиране на стрингове. Освен това са стандартни. Единственият проблем е промяната
на нагласата (трудно се променя мисленето в стил %).

Моля те подписвай постовете си. Имам чувството, че говоря на стената.

Стриймовете са добра идея за форматиране. Малко многословни -- май отива към 3 реда код за създаване на стрийм, запис в него и извличане на низа. Ама това не е болка за умиране и се оправя.

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

ami "%s%2.3f%04d" сещаш ли се как става със stringstream..... мързи ме да пиша толкова.
----
бтв от МС са големи перверзници - в VC7 компилаторът проверява формат.низа и дава warnings ако има проблеми....

В тежест ми е само създаването на стрийма.
Обаче в замяна мога да използвам добре дефиниран operator << , което пести
писане и възможности за грешка.

Лесно става, <iomanip> дава всичко необходимо.
Стрийм моделът напълно се възползва от проверката на типовете, така че
особено в това отношение е за предпочитане пред format начина.

абе знам, че може и че е за предпочитане.
ама вместо

Log("Big shit happened here %s, invalid values %d;%d.", loc, val1, val2),

става примерно

log << "Big shit happened here " << loc <<
", invalid values " << val1 << ";" << val2 << ".";

да не говорим, ако има някво друго форматиране, камо ли пък формат. низа ако се взима от ресурс.

-----------
a в boost има едно нещо, дето е като на С# - хем с формат. низове, хем typesafe.

В отговор на:

---

Лесно става, <iomanip> дава всичко необходимо.

---

Тук май удряме същия проблем като в мрънкането за std::string и char*. Как да обясним какво е ио манипулатор на студента дето досега в проектчетата в университета е бичил със printf подобия? То хайде това е лесно -- дори и с насилване става. Как обаче да обясним същото на някои стари (и леко ръждиви) пушки дето още могат да те изгърмят на база, че имат повече опит? Абе на мен са ми правили проблеми като съм ползвал exceptions в C++ . Има хора, за които C и C++ са един и същи език . На моменти почвам да си мисля, че големия избор от средства в някои езици не е предимство ами недостатък.

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