Z większością rzeczy się zgadzam, ale pozwól, że wtrące swoje małe "ale" :)

Ad 1) - jakiś czas temu zacząłem używać regionów na potęgę (regioneratethis rządzi!). Jednak warto imho tutaj być ostrożnym. Regiony pozwalają nadać kodzie blasku , który niekoniecznie semantycznie do końca może być tak efektowny. Chodzi mi o to, żeby nie wdać się w automatyczne "zamykanie" kodu, który uważamy za nie do końca dopracowany. "Zamknę go w region i bedzie cacy" - spowoduje poczucie, że klasa wygląda schludnie i zwarto. Osobiście zaprzestałem używania regioneratethis z tego własnie powodu a preferuje widok classview (lub FileStructure jeśli ktoś używa R#). Natomiast jeśli obsługujemy np. wszystkie eventy wywoływane przez np. GridView to ...bez regionów ciężko:) Krótko: regionów uzywać, ale z głową i nie dać im się omamić:)

Ad 6) - Dodam tylko, że w takich przypadkach teraz też mamy Extension Methods - warto używać.

Reszta, a w szczególności (11) (- mam identyczne spostrzeżenie) warta zapamietania.
Aha, drobna sugestia, mógłbyś zmienić kolor komentarzy na ciut jaśniejszy? Światło mi z rana intensywnie pada na monitor i dopiero pod koniec zauważyłem w ogóle, że są:)

Mam kilka komentarzy:

Ad 1) Osobiście staram się umieszczać opis regionu również po dyrektywie #endregion, w ten sposób:

#region <Opis>
#endregion <Opis>

Przy rozwiniętych regionach minimalnie polepsza to czytelność kodu.

Ad 4) Podlinkowana wersja dokumentu ".NET Framework General Reference - Naming Guidelines" dotyczy .NET Framework 1.1 (hint: VS.NN w adresie oznacza wersję dokumentu. VS.71 oznacza .NET 1.1, VS.80 - .NET 2.0, VS.85 - .NET 3.0, VS.90 - .NET 3.5. Można usunąć nawias i wtedy dostaniemy najnowszą wersję. Akurat ten konkretny dokument dotyczy wyłącznie .NET 1.1). Aktualna wersja jest dostępna pod adresem msdn2.microsoft.com/en-us/library/ms229002.aspx.

Ad 5) Wszelkiego rodzaju skrócone notacje to najczęściej broń obosieczna. Szczególnie skrócona notacja warunkowa, osobiście nie polacałbym jej nikomu w ramach best practices. Wygląda to świetnie na papierze, ale z moich obserwacji wynika, że stosowanie jej, choć zwiększa zwięzłość, najczęściej wpływa negatywnie na czytelność kodu. Próbujemy w jednej linii zmieścić praktycznie trzy wyrażenia, więc często zdarza się, że całe wyrażenie wraz z odstępami jest szersze, niż szerokość ekranu, nawet, jeśli jest bardzo proste (ot np. gdy wywołujemy w nim metodę, która przez przypadek ma bardzo wylewną nazwę).

Spotkałem się z takim zapisem:

if (w != null) {
return w.Object;
}
return GetDefaultObject();

i to jest według mnie w miarę zwięzłe (średnio 2, 3 linie mniej, niż gdy stosujemy else), a już na pewno bardzo czytelne.

Ad 7)

DO NOT use public nested types as logical grouping construct; use namespaces for this.
AVOID publicly exposed nested types. The only exception to this is if variables of the nested type need to be declared in rare scenarios such as subclassing or other advanced customization scenarios.
DO NOT use nested types if the type is likely to be referenced outside of the containing type.

Źródło: Krzysztof Cwalina, Brad Adams, Framework Design Guidelines: Conventions, Idioms and Patterns for Reusable .NET Libraries

Ja się zgadzam z autorami w tej kwestii - definiowanie zagnieżdżonych typów wyliczeniowych w żadnym wypadku nie jest najlepszą praktyką, typy nie służą do grupowania. Jeśli spróbujemy skonsumować taki typ wyliczeniowy gdzieś w kodzie, dostaniemy:

Person.PersonGender gender = Person.PersonGender.Female;

a z czymś takim zdaje się próbowaliści walczyć w punkcie 2). Tu sytuacja jest trochę gorsza, bo nie pomoże nam prosty prosta deklaracja użycia przestrzeni nazw (w końcu Person nią nie jest). Możemy skorzystać jedynie z aliasów:

using Gender = Person.PersonGender;
...
Gender gender = Gender.Female;

ale:

a) Visual Studio w żaden sposób nie zautomatyzuje nam tworzenia takiego aliasu (w przypadku przestrzeni nazw wystarczyło wpisać nazwę typu, a resztę załatwiał smart tag).

b) Rozpętamy piekło. Jeden programista utworzy alias Gender, drugi Sex, a trzeci, który będzie to potem czytać i który przypadkiem jest autorem oryginalnego kodu, będzie się zastanawiać: Gdzie ja u licha zadeklarowałem typ "Sex"?.

Osobiście w przypadku, gdy typ wyliczeniowy jest powiązany z jedną klasą, definiuję go po prostu w tym samym pliku, co klasę, najlepiej jeszcze przed jej definicją. I to jest rozwiązanie podobne do Twojego, ale pozbawione jego wad.

Ad 11) Nie widzę przeciwwskazań również w przypadku, gdy inijcjalizujemy zmienną nowo utworzonym obiektem, np.:

StringBuilder sb = new StringBuilder();

-- vs --

var sb = new StringBuilder();

(albo coś bardziej życiowego)

ConnectionEndPointSecurityInformationProvider provider = new ConnectionEndPointSecurityInformationProvider()

-- vs --

var provider = new ConnectionEndPointSecurityInformationProvider();

Znam dwie osoby, które wiedzą wszystko, jedną z nich jest Tomek Kopacz, a żadną z nich nie jestem ja. I wiem, że naprawdę sporo mi do nich brakuje. Zresztą spytaj Kuby J., zagiął mnie raz pytaniem :). Co do moich programistycznych przyzwyczajeń, to pewnie jest tego cała masa, ale tak na szybkiego nic mi nie przychodzi do głowy. O, wiem. Nigdy nie piszę "this.". Nigdy nie używam SCREAMING_CAPS w nazwach stałych. Stosuję nadenkapsulację, tj. enkapsuluję wszystko i wszędzie i staram się nigdy nie odwoływać do prywatnych pól spoza metod dostępowych lub konstruktora.

Mam kilka uwag technicznych odnośnie mechanizmu komentowania na blogu. Czy dałoby radę pozbyć się wcięcia na początku pierwszego akapitu? Jest trochę jak Hiszpańska Inkwizycja, nikt się go nie spodziewa. I czy dałoby radę wprowadzić dwa nowe znaczniki formatowania:

tekst

, zamieniany na <pre>tekst</pre> oraz [url=adres]tekst[/url], zamieniany na <a href="adres">tekst</a>? Tych dwóch funkcji szczególnie mi brakuje.

Na koniec jeszcze jedna rzecz, którą chciałem skomentować, a jakoś mi umknęła wcześniej:

Ad 10) Zapisywanie warunków w ten sposób:

if (warunek == false) return;

może przynieść więcej szkody, niż pożytku. Wyrażenia logiczne, w których lewa strona porównania jest typu logicznego i jest l-wartością, są jako jedyne w całym języku C# podatne na coś, co można nazwać błędem nieumyślnego przypisania w warunku:

// Jakiś skomplikowany warunek.
bool canAdd = ... ;
// Warunek będzie zawsze ewaluowany do false - na pewno tego chcieliśmy?
if (canAdd = false) throw new IvalidOperationException("Item cannot be added to the collection.");

Takie błędy są szalenie trudne do zauważenia, szczególnie w C#, gdzie praktycznie ciężko jest je popełnić.

Jeśli koniecznie chcemy mieć binarny operator i literał typu bool w warunku (choć ja nie widzę sensu), możemy zabezpieczyć się przed efaktami ubocznymi korzystając z klasycznego rozwiązania znanego z C++:

if (false == canAdd) throw new IvalidOperationException("Item cannot be added to the collection.");

Teraz wszystko jest niby OK, ale składnia ta jest na tyle niecodzienna w C#, że u nieprzyzwyczajonego czytelnika może powodować przestoje przy czytaniu kodu.

Ad 1)
Ja używam jeszcze innej konwencji z regionami:
#region <Opis>
#endregion //<Opis>

Dla mnie takie użycie daje najlepszą czytelność przy rozwiniętych regionach - bo mam nazwę regionu i od razu po kolorze rozróżniam czy to początek czy koniec.

Ad 10)
Ja mimo wszystko się nie zgodzę co do (warunek == false), z resztą zdziwiło mnie właśnie na C2C, że Paweł tak pisał, bo taki kod bardzo łatwo prowadzi do magicznych kwiatków w stylu

if (warunek == false)
return false;
else
return true;

Ad 5) Te akurat lubię bardzo, a chciałem tylko dodać do ?? że można to sobie rozwinąć jeszcze bardziej, np.:
int? x = null;
int? y = null;
int? z = null;
int? aa = 5;
int? cosik = x ?? y ?? aa ?? z; // co zwróci, a?

Ad 10)
if-a nie polecam, lepszy jest if (warunek), zbyt często robiło mi się if (warunek = true) ;)

Oprócz 7 punktu reszta jest codziennością. :) Co do 7 nie zagnieżdżam typów. :)

10)
a ja zawsze pisze !warunek bo tak jest jednak lepiej.
latwiej sie czyta i nie ma problemow z = zamiast ==.
koniec.

Coś jest nie tak, jak patrzę na mój komentarz z 10 kwietnia 2008 15:37, to on się już podporządkował nowemu formatowaniu, ale z niewiadomych przyczyn tekst za blokiem pre jest pomniejszony.

Spróbujmy zreprodukować:

Tekst przed blokiem pre
[pre]Tekst wewnątrz bloku pre[/pre]
Tekst za blokiem pre

Tfu, blokiem code :)

Tekst przed blokiem code

Tekst wewnątrz bloku pre

Tekst za blokiem code

Pobawiłem się Firebugiem i wiem, z czego wynika wcięcie w pierwszym akapicie. W każdym komentarzu znajduje się coś takiego:

<p class="gravatar"/>

Klasa gravatar ma następującą definicję CSS:

.comment .gravatar {

   float:left;

   margin:5px 10px 5px 0pt;

}

Wszystko przez float:left, powoduje on powstanie kwadracika 10x10px, który jest otaczany tekstem. Wydaje mi się, że ten element nie jest w ogóle używany (to jest chyba miejsce na awatar), więc możesz rozwiązać problem dopisując do definicji stylu:

display:none;

Jets sobie zmienna:

object f = null;

Jaki bedzie lepszy sposob na przekonwertowanie f na doubla, ktory przyjmnie wartosc 0 jesli f jest nullem?

double d1 = System.Convert.ToDouble(f ?? 0);

czy

double d2 = Double.Parse(f == null ? "0" : f.ToString());

pomylka, w przypadku nulla miala byc wartosc 1, a wiec:
double d1 = System.Convert.ToDouble(f ?? 1);
czy
double d2 = Double.Parse(f == null ? "1" : f.ToString());