Struktura funkcji - nazewnictwo - zasada jednej operacji Opcje

[jackraymund]

Witam,
walczę z nazewnictwem

[PHP] pobierz, plaintext 
$companyId = $this->updateCompanySetToArrayAndGetId($matchedData['company']);//wywolanie
public function updateCompanySetToArrayAndGetId($aCompanyName)
	{
	$isCompanyExistInArray = in_array($aCompanyName,$this->companyArray);
	if(!$isCompanyExistInArray)
	  {
	  $companyId = $this->sqlUpdater->updateCompanyAndGetId($aCompanyName);
	  $this->companyArray[$companyId] = $aCompanyName;
	  return $companyId;
	  }
	else
	  return array_search($aCompanyName,$this->companyArray);
	}
[PHP] pobierz, plaintext 

Z zasady, jedna funkcja, jedna operacja,ten kod jest okropny, lecz zarazem nazwa tej funkcji jest okropna(pomijając tą zasadę).
Natomiast załóżmy że chciałbym zrobić to na tej zasadzie i zrobić to w miarę optymalnie.(chodzi o to, aby nie wywołać funkcji z sqlUpdater, gdy rekord znajduje się aktualnie w tablicy).

Jestem otwarty na wszelakie pomysły.

Pozdrawiam

[com]

Skoro przeczytałeś czysty kod chwała Ci za to ale skoro już o tym mowa:

Nie ma nic bardziej pomocnego i satysfakcjonującego, jak dobrze opisane publiczne API. Przykładem
tego może być standardowa biblioteka Java. Bez niej pisanie programów Java byłoby trudne,
o ile nie niemożliwe.
Jeżeli piszemy publiczne API, to niezbędne jest napisanie dla niego dobrej dokumentacji Javadoc.
Jednak należy pamiętać o pozostałych poradach z tego rozdziału. Komentarze Javadoc mogą być
równie mylące, nie na miejscu i nieszczere jak wszystkie inne komentarze

Tobie się przyda czytanie zrozumieniem. Czy ja Ci daje rady pisz sobie jak chcesz, możesz komentarzy nie dawać, nikt Ci tego nie zabroni. Wyjaśniłem Ci tylko czemu tego się używa, to że zaciemnia kod to ja wcale nie twierdze że tak nie jest. Ale dlatego też w łatwy sposób można je z pliku usunąć (IMG:style_emoticons/default/smile.gif)

Kolejny co odbiera wszystko personalnie i ma ból tyłka potem, daruj sobie (IMG:style_emoticons/default/smile.gif)

Poza tym nawet nie zrozumiałeś tego co napisał Pyton_000, który wyraźnie napisał:

@NickOver miał na myśli komentowanie kodu samego w sobie, nie komentarze dla funkcji czy klasy bo to oczywiście obowiązkowe.

[Dejmien_85]

Skoro przeczytałeś czysty kod chwała Ci za to ale skoro już o tym mowa:

Przeczytałem i cieszy mnie to, że Ty też się w tym orientujesz, choć jak widać się nie stosujesz - ten tekst o publicznym API także pamiętam. Jest to jednak jedyny przypadek, kiedy dokumentacja *może* zostać użyta rozsądnie.

Nie wykluczam tej opcji, pragnę tylko podkreślić fakt, że pisanie dokumentacji "na mus" jest niczym więcej jak generowaniem masy zbędnego i rozpraszającego tekstu. Tak, komentarze są szare (z natury), można nawet przy pomocy IDE zmienić kolor na inny, ale to nie zmienia faktu, że komentarze są w większości przypadków po prostu kompletnie zbędne i nastawienie "there shall be comments!" prowadzi do chaosu.

Dobra, wystarczy na dzisiaj tych kazań, idziem spać!

Szerokości.