De Devschuur Coffee Corner - Iteratie 5

[F.West98]

Wauw.
Het is dat ik al bij Strato wou opzeggen, maar ze hebben me nu buitengesloten uit m'n VPS. Ze hebben mijn wachtwoord laten verlopen en een andere ingesteld, die ik niet weet.

[RayNbow]

PrisonerOfPain schreef op zondag 16 februari 2014 @ 19:57:
[...]

Logging heeft toch gewoon zin? Het is extreem handig bij post-mortem crash analysis - of uberhaupt om te analyseren wat een gebruiker doet. Verder is het handig om te loggen wat voor data er door je programma heen gaat.

Ja, maar het loggen doe je dus in het I/O gedeelte van je programma. Het heeft weinig nut om te loggen in pure functies.

[...]

Is dat dan niet een beetje appels met peren vergelijken? Je zult toch nog steeds Quux af moeten handelen ondanks dat het in een try/catch blok staat?

Quux moet inderdaad op een gegeven moment worden afgehandeld, maar dat kan op meerdere manieren. Je kunt expliciet pattern matchen op het resultaat, e.g.,

Haskell:

s = case foo 3 of 
      Left someQuuxValue -> "Okay, something went wrong"
      Right x            -> "We got a nice integer: " ++ show x

maar je kunt ook bijv. functies van de vorm a -> Either e b combineren en het afhandelen verwerken in een combinator. Door het in een handige combinator te verpakken kun je onderstaande code

Haskell:

t1 = case foo 3 of 
       Left someQuuxValue -> "Okay, something went wrong"
       Right x            -> case foo x of
                               Left someQuuxValue -> "Okay, something went wrong"
                               Right y            -> "Got: " ++ show y

herschrijven naar het volgende:

Haskell:

t2 = case (foo <=< foo) 3 of 
       Left someQuuxValue -> "Okay, something went wrong"
       Right y            -> "Got: " ++ show y

Nog steeds moet je ergens in je programma iets doen met Quux, maar met behulp van een slimme combinator kun je het aantal keren dat je dat moet doen flink beperken.

Een beter voorbeeld is misschien het veelvoudig controleren op nullwaarden in imperatieve talen. In het overdreven stukje code hieronder wordt meerdere malen op null gecheckt:

C#:

String GetZipCodeAsString(Person p) {
    String res = null;
    
    if (person != null) {
        Address address = person.GetAddress();
        if (address != null) {
            ZipCode zipCode = address.GetZipCode();
            if (zipCode != null) {
                res = zipCode.ToString();
            }
        }
    }
    return res;
}

In talen als F# en Haskell kun je dit null-check-patroon abstraheren in een aantal combinators en kun je het bovenstaande voorbeeld kort en bondig opschrijven:

Haskell:

getZipCodeAsString :: Maybe Person -> Maybe String
getZipCodeAsString maybePerson =
  do p <- maybePerson
     address <- getAddress p
     zipCode <- getZipCode address
     return (show zipCode)

[Caelorum]

Och, ik laat gewoon die null checks vaak zitten. Eerste persoon die code schrijft die een null in die functie probeert te stoppen krijgt een foutmelding van het systeem en mag zijn code herschrijven. Het is meer een gedachte/gewoonte dat null checks nodig zijn in C# dan dat het echt nodig is.
Zelfde als overvloedig gebruik van exceptions. Een exception gooien is, vind ik, vrijwel nooit nodig in C#. .Net doet het vaak wel voor je waar nodig en door het niet af te vangen vind je de oorzaak snel genoeg. Belangrijkste is IMO nog steeds om code te schrijven die die exceptions niet eens triggered.

Wil niet zeggen dat ik beide niet gebruik, maar zorg er wel voor dat ze zo weinig mogelijk voorkomen.

[ Voor 8% gewijzigd door Caelorum op 16-02-2014 21:57 ]

[F.West98]

Caelorum schreef op zondag 16 februari 2014 @ 21:55:
Och, ik laat gewoon die null checks vaak zitten. Eerste persoon die code schrijft die een null in die functie probeert te stoppen krijgt een foutmelding van het systeem en mag zijn code herschrijven. Het is meer een gedachte/gewoonte dat null checks nodig zijn in C# dan dat het echt nodig is.
Zelfde als overvloedig gebruik van exceptions. Een exception gooien is, vind ik, vrijwel nooit nodig in C#. .Net doet het vaak wel voor je waar nodig en door het niet af te vangen vind je de oorzaak snel genoeg. Belangrijkste is IMO nog steeds om code te schrijven die die exceptions niet eens triggered.

Wil niet zeggen dat ik beide niet gebruik, maar zorg er wel voor dat ze zo weinig mogelijk voorkomen.

QFT
nullchecks doe ik nog wel eens, maar Exceptions vrijwel nooit. Wel correcte afhandeling natuurlijk

[BikkelZ]

RayNbow schreef op zondag 16 februari 2014 @ 21:20:
[...]

Ja, maar het loggen doe je dus in het I/O gedeelte van je programma. Het heeft weinig nut om te loggen in pure functies.


[...]

Quux moet inderdaad op een gegeven moment worden afgehandeld, maar dat kan op meerdere manieren. Je kunt expliciet pattern matchen op het resultaat, e.g.,

Haskell:

s = case foo 3 of 
      Left someQuuxValue -> "Okay, something went wrong"
      Right x            -> "We got a nice integer: " ++ show x

maar je kunt ook bijv. functies van de vorm a -> Either e b combineren en het afhandelen verwerken in een combinator. Door het in een handige combinator te verpakken kun je onderstaande code

Haskell:

t1 = case foo 3 of 
       Left someQuuxValue -> "Okay, something went wrong"
       Right x            -> case foo x of
                               Left someQuuxValue -> "Okay, something went wrong"
                               Right y            -> "Got: " ++ show y

herschrijven naar het volgende:

Haskell:

t2 = case (foo <=< foo) 3 of 
       Left someQuuxValue -> "Okay, something went wrong"
       Right y            -> "Got: " ++ show y

Nog steeds moet je ergens in je programma iets doen met Quux, maar met behulp van een slimme combinator kun je het aantal keren dat je dat moet doen flink beperken.

Een beter voorbeeld is misschien het veelvoudig controleren op nullwaarden in imperatieve talen. In het overdreven stukje code hieronder wordt meerdere malen op null gecheckt:

C#:

String GetZipCodeAsString(Person p) {
    String res = null;
    
    if (person != null) {
        Address address = person.GetAddress();
        if (address != null) {
            ZipCode zipCode = address.GetZipCode();
            if (zipCode != null) {
                res = zipCode.ToString();
            }
        }
    }
    return res;
}

In talen als F# en Haskell kun je dit null-check-patroon abstraheren in een aantal combinators en kun je het bovenstaande voorbeeld kort en bondig opschrijven:

Haskell:

getZipCodeAsString :: Maybe Person -> Maybe String
getZipCodeAsString maybePerson =
  do p <- maybePerson
     address <- getAddress p
     zipCode <- getZipCode address
     return (show zipCode)

Er is een uitbreiding op C# uitgekomen die volgens mij de hele reut in één regel kan, zoiets als ?? maar dan beter. Laat me even Googlen.

------

Aha, het heet Monadic Null checking http://damieng.com/blog/2...-6-0-features-illustrated

C#:

string GetZipCodeAsString(Person p)
{
    return person?.GetAddress()?.GetZipCode();
}

[ Voor 4% gewijzigd door BikkelZ op 16-02-2014 22:16 ]

[Caelorum]

BikkelZ schreef op zondag 16 februari 2014 @ 22:12:
[...]
Er is een uitbreiding op C# uitgekomen die volgens mij de hele reut in één regel kan, zoiets als ?? maar dan beter. Laat me even Googlen.

Maybe monad?

[RobertMe]

Je bedoeld waarschijnlijk deze. Maar deze lijkt beperkt te zijn tot iets als 'foo ?? "bar"', er vanuit gaande tot foo een string is krijg je dus of de waarde van die string, of "bar" terug. Iets als 'foo.Length ?? 0' zal je hiermee niet lukken voor zover ik kan zien.

En het door velen hier gehate taalje PHP ondersteund dit sinds kort ook in de vorm van ?: (ternary zonder "true" operhand").

[BikkelZ]

RobertMe schreef op zondag 16 februari 2014 @ 22:17:
Je bedoeld waarschijnlijk deze.

Nope die bestaat al heel lang, dit is een C# 6.0 feature. Het kan met ?? ook in één regel maar dan wordt het wel een beetje kliederig. Overigens ga je een Haskell vs. C# discussie niet winnen met het feit dat er Monads of Monad-achtige dingen aan C# toegevoegd worden natuurlijk

[Caelorum]

BikkelZ schreef op zondag 16 februari 2014 @ 22:20:
[...]
Nope die bestaat al heel lang, dit is een C# 6.0 feature. [...]

Het artikel zegt waarschijnlijke C#6.0 features. Ik kan nergens vinden dat dit er echt komt.

[Cartman!]

RobertMe schreef op zondag 16 februari 2014 @ 22:17:
En het door velen hier gehate taalje PHP ondersteund dit sinds kort ook in de vorm van ?: (ternary zonder "true" operhand").

Sinds PHP5.3 dus al jaren en nee, nog nooit gebruikt eigenlijk.

[Firesphere]

Cartman! schreef op zondag 16 februari 2014 @ 22:31:
[...]

Sinds PHP5.3 dus al jaren en nee, nog nooit gebruikt eigenlijk.

Het is wel handig als je echt even shorthand nodig hebt en de boel compact wil houden. Ik gebruik het alleen als ik een bepaalde waarde uit een array wil hebben terwijl ik niet zeker weet of die wel bestaat.

PHP:

return (isset($array[$value])) ? $array[$value] : false;

Maar mooi is het zeker niet.

[BikkelZ]

Caelorum schreef op zondag 16 februari 2014 @ 22:24:
[...]

Het artikel zegt waarschijnlijke C#6.0 features. Ik kan nergens vinden dat dit er echt komt.

Mads Torgersen, head program manager of C#

Denk dat de grote vraag niet is of maar wanneer we het krijgen. Het is ook een redelijk triviale toevoeging volgens mij.

[F.West98]

Ik hoop met Windows 8.2 of Windows 9.
Is namelijk wel heel cool

[Caelorum]

Wat heeft windows te maken met .net of zelfs maar c#?

[ Voor 19% gewijzigd door Caelorum op 16-02-2014 22:53 ]

[F.West98]

Kijkend naar het verleden, werden nieuwe C#-versies pas beschikbaar met een .NET-versie (Wikipedia: C Sharp (programming language)) en .NET vaak met een nieuwe Windows (Wikipedia: .NET Framework)

Misschien niet tegelijk (de eerste twee), maar ik ga pas C#6 gebruiken als er .NET voor is...

[Alex)]

Zolang de CLR niet verandert maakt het weinig uit.

[Rutix]

Dus jullie gebruiken geen custom exceptions ofzo? Wij gebruiken ze wel en ik vind ze rete handig. Vooral als je het combineert met logging en een duidelijke onderscheid maakt tussen exceptions die de application helemaal mogen laten crashen of exceptions die meer functioneel zijn.

En ik doe echt wel null checks op methods die public zijn. Het is veel beter om daar dan al een ArgumentNullException te gooien dan dat je een stack trace krijgt die heel diep gaat en waar het niet echt duidelijk is of het een fout is dieper of meer aan het begin.

F.West98 schreef op zondag 16 februari 2014 @ 23:03:
Misschien niet tegelijk (de eerste twee), maar ik ga pas C#6 gebruiken als er .NET voor is...

Waarom dat? Een nieuwe C# versie hoeft niet gelijk te staan aan nieuwe .NET versie. Ik zie niet in waarom je niet C#6 features zou gebruiken zo gauw ze uit zijn.

[ Voor 25% gewijzigd door Rutix op 16-02-2014 23:16 ]

[Alex)]

Op public en internal methods doe ik ook aan null checks. Custom exceptions gebruik ik vooral veel in repositories, maar dan is het wel afhankelijk van hoe iets werkt.

Bij Get-methods (zoals GetCustomer) retourneer ik null als iets niet bestaat, bij methods waarvan je kunt verwachten dat de customer bestaat (bijvoorbeeld bij het plaatsen van een order) gooi ik een exception als de customer waarvoor de order is bedoeld niet bestaat.

[F.West98]

Rutix schreef op zondag 16 februari 2014 @ 23:14:
Dus jullie gebruiken geen custom exceptions ofzo? Wij gebruiken ze wel en ik vind ze rete handig. Vooral als je het combineert met logging en een duidelijke onderscheid maakt tussen exceptions die de application helemaal mogen laten crashen of exceptions die meer functioneel zijn.

En ik doe echt wel null checks op methods die public zijn. Het is veel beter om daar dan al een ArgumentNullException te gooien dan dat je een stack trace krijgt die heel diep gaat en waar het niet echt duidelijk is of het een fout is dieper of meer aan het begin.

In de back-end code moet je niet te veel met Exceptions spelen
Ik geef wel Exceptions naar de user (met een try/catch en dan een messagebox) als iets niet kan. Maar niet IN de back-end, dat doe ik vrijwel exception-loos (want dan gaat VS daar ook steeds op stoppen met debuggen enzo (want soms wil ik WEL in een try/catch breaken)).

[...]


Waarom dat? Een nieuwe C# versie hoeft niet gelijk te staan aan nieuwe .NET versie. Ik zie niet in waarom je niet C#6 features zou gebruiken zo gauw ze uit zijn.

Ik had het ergens gelezen + de zo ogende koppeling op Wikipedia deed mij een verband vermoeden. Blijkt niet zo te zijn.

[Rutix]

F.West98 schreef op zondag 16 februari 2014 @ 23:20:
[...]

In de back-end code moet je niet te veel met Exceptions spelen
Ik geef wel Exceptions naar de user (met een try/catch en dan een messagebox) als iets niet kan. Maar niet IN de back-end, dat doe ik vrijwel exception-loos (want dan gaat VS daar ook steeds op stoppen met debuggen enzo (want soms wil ik WEL in een try/catch breaken)).

Ben ik niet met eens. Waarom zou je geen exceptions vanuit de backend naar boven mogen gooien? Dat je ze niet catched in de backend is wat anders. Maar jij zegt "exceptions spelen" en daar valt ook throwen onder.

[F.West98]

Ik gooi ook exceptions uit de back-end naar de front-end, maar niet in de back-end naar de back-end (tenminste, niet veel). Wat ik meestal doe is bijvoorbeeld een .FirstOrDefault en daarna een nullcheck, maar er kan verder niet zo veel mis gaan (ik heb alle punten waar het fout kan gaan direct een error naar de user toe, is toch een Admin-UI). Zeker omdat sommige dingen moeten werken zonder user-interactie (cronjobs) is het onhandig om daar error-handling te doen, kan je beter op de plek van de fout iets loggen ipv throwen en dan de hele actie stoppen (of weer een try/catch maken en dán loggen (what's the difference?)).

User-UI doe ik wel veel meer met foutafhandeling, maar dan ook niet in de vorm van Exceptions (user-acties zijn simpele DB-acties die verder niet ingewikkeld zijn en geen Exception zouden moeten geven). Alle Exceptions vanuit systeem worden gelogged en er wordt dan geprobeerd verder te gaan.

In de app die ik met een vriend maak (ik doe niet zo veel) wordt wel veel gebruik gemaakt van Exceptions. Daar merk ik dat er heel veel "noise code" in de exception-handling zit (opnieuw throwen voor de user, met usertekst; verschillende catchblokken (java)) en dat ik die ook steeds blijf maken (wat erg irritant is).

edit: het slaat vast nergens op, maar ik vind het onhandig en dat is een kwestie van gewoonte, het werkt voor mij prima.

[ Voor 3% gewijzigd door F.West98 op 16-02-2014 23:39 ]

[BikkelZ]

Betere een Exception dan een return null. Waarbij je op een andere regel een nullpointer exception krijgt omdat je er verder niks mee kan. Een programma hoort te falen op de plek waar het fout gaat. Maar goed als je in functie A checkt op null van de user input en met die string vervolgens functie B aanroept en je gaat daar op null lopen checken dan is dat natuurlijk extreem overbodig.

Return null kan natuurlijk wel als je echt iets als undefined wil terugsturen, bijvoorbeeld een int? die nog niet gezet is of juist gecleared moet worden.

[ Voor 21% gewijzigd door BikkelZ op 16-02-2014 23:43 ]

[F.West98]

BikkelZ schreef op zondag 16 februari 2014 @ 23:42:
Betere een Exception dan een return null. Waarbij je op een andere regel een nullpointer exception krijgt. Een programma hoort te falen op de plek waar het fout gaat. Maar goed als je in functie A checkt op null van de user input en met die string vervolgens functie B aanroept en je gaat daar op null lopen checken dan is dat natuurlijk extreem overbodig.

Vaak wil ik als het null is iets anders doen (een nieuw element aanmaken), dan is het onhandig om dat dan (achteraf als je je bedenkt dat het null kan zijn) alles weer in een catch te gaan gooien, een exception te gaan throwen in de andere functie, een exception maken (soms). Dan doe ik liever een if(foo == null) en gaan met die banaan. Zeker als ik dan bar anders maak, en ik foo == null verderop ook nog gebruik voor gewenst gedrag. Algemeen geldende dingen voor de hele functie/iteratie.

[Caelorum]

Rutix schreef op zondag 16 februari 2014 @ 23:14:
Dus jullie gebruiken geen custom exceptions ofzo? [...]

Ik geef de voorkeur aan op voorhand duidelijk maken wat acceptabele input is voor een functie. Al het andere input mag best er in worden gestopt, maar dan moet je ook niet muiten als de functie halverwege stopt met een exception. Ik handel overigens wel netjes de .net exception af waar nodig is, maar geef gewoon de voorkeur niet zoveel exceptions en null checks te doen. Zo'n functie als

C#:

 public string composeNameString(Person person);

tja.. Als je daar zelf een null waarde in gaat stoppen of een person object die niet compleet is, dan zoek je het zelf maar uit. Ik geef wel in de functiedocumentatie aan wat acceptabele input is. Verder geef ik al helemaal de voorkeur dat objecten gewoon altijd de correcte staat hebben zodat een functie altijd werkt.
Overigens is het voorbeeld wat ik heb gegeven hierboven wel een beetje gaar, want null waardes is wat mij betreft nooit acceptabele input.
Hoe dan ook zal de functie vanzelf onderuit knallen met een nullreferenceexception en is het duidelijk wat er mis is.
Custom exceptions ben ik op zich niet op tegen, maar dan wel voor exceptions en niet voor zaken die niet uitzondering zijn. Exceptions gooien voor input die je niet verwacht hoeft wat mij betreft niet, want het is uit de functiedocumentatie wel duidelijk wat fatsoenlijke input is. En dan blijft er ineens vrij weinig over waar je exceptions voor moet gooien.

[ Voor 18% gewijzigd door Caelorum op 16-02-2014 23:47 ]

[Rutix]

F.West98 schreef op zondag 16 februari 2014 @ 23:38:
Ik gooi ook exceptions uit de back-end naar de front-end, maar niet in de back-end naar de back-end (tenminste, niet veel). Wat ik meestal doe is bijvoorbeeld een .FirstOrDefault en daarna een nullcheck, maar er kan verder niet zo veel mis gaan (ik heb alle punten waar het fout kan gaan direct een error naar de user toe, is toch een Admin-UI). Zeker omdat sommige dingen moeten werken zonder user-interactie (cronjobs) is het onhandig om daar error-handling te doen, kan je beter op de plek van de fout iets loggen ipv throwen en dan de hele actie stoppen (of weer een try/catch maken en dán loggen (what's the difference?)).

User-UI doe ik wel veel meer met foutafhandeling, maar dan ook niet in de vorm van Exceptions (user-acties zijn simpele DB-acties die verder niet ingewikkeld zijn en geen Exception zouden moeten geven). Alle Exceptions vanuit systeem worden gelogged en er wordt dan geprobeerd verder te gaan.

In de app die ik met een vriend maak (ik doe niet zo veel) wordt wel veel gebruik gemaakt van Exceptions. Daar merk ik dat er heel veel "noise code" in de exception-handling zit (opnieuw throwen voor de user, met usertekst; verschillende catchblokken (java)) en dat ik die ook steeds blijf maken (wat erg irritant is).

edit: het slaat vast nergens op, maar ik vind het onhandig en dat is een kwestie van gewoonte, het werkt voor mij prima.

De redenen die nu aanhaalt zijn erg specifiek voor jou huidige code base terwijl je net een stelling maakte die impliceerde dat je het in het algemeen bedoelde. Ik vind namelijk dat, vooral als je software project groot word, het handig is om gebruik te maken van user defined exceptions. Hierdoor word het meteen duidelijk waar de fout zit, wat voor soort fout is, je kunt het makkelijk catchen in user interface code, makkelijk om ook onderscheid te maken tussen functionele fouten en keiharde crash fouten.

Daarnaast is wat BikkelZ zegt natuurlijk helemaal waar, je moet niet onnodige checks gaan doen. Daarom doe ik vaak geen nullchecks in private methods omdat die checks al gedaan zijn in de public die de privates aanroepen.

EDIT:

Als ik de reacties zo lees dan krijg ik het idee dat iedereen denkt dat ik custom exceptions bedoel in combinatie met null objecten. Ik bedoel custom exceptions meer algemeen, dus als er iets fout is in de business logic bijvoorbeeld.

[ Voor 57% gewijzigd door Rutix op 16-02-2014 23:48 ]

[Caelorum]

Rutix schreef op zondag 16 februari 2014 @ 23:44:
[...]
Als ik de reacties zo lees dan krijg ik het idee dat iedereen denkt dat ik custom exceptions bedoel in combinatie met null objecten. Ik bedoel custom exceptions meer algemeen, dus als er iets fout is in de business logic bijvoorbeeld.

Ik kan daar niet over oordelen. Ik heb praktisch geen ervaring met code met echt complexe business logic. Ik vermoed dat het in zo'n geval handig zou kunnen zijn, al denk ik wel dat er al snel teveel verschillende exceptions worden aangemaakt. Het enige wat ik kan zeggen is dat ik persoonlijk vrijwel nooit zelf exceptions hoef te schrijven, maar vaak genoeg heb aan wat er al aanwezig is in .Net en dat ik zelfs die spaarzaam gebruik. Dat kan heel goed een teken zijn van de codebases waar ik zelf aan werk.

[ Voor 4% gewijzigd door Caelorum op 16-02-2014 23:53 ]

[BikkelZ]

Hangt er ook van af wat voor applicatie het is. Een eenmansproject is bij mij doorgaans wat slordiger dan een groepsproject omdat ik gewoon niet zo veel hoef uit te leggen over de code en ik crappy delen heel makkelijk kan refactoren op een moment dat mij dat uit komt.

Als je in een groter project met een groter team over langere tijd werkt dan moet iets wat je maakt logisch in elkaar zitten en bruikbare foutmeldingen opleveren zodat over drie jaar iemand uit India in de logfiles kan zien dat er uit de database op de een of andere manier nulls in de id's zitten. Bij wijze van spreken.

Goede exceptions horen gewoon bij documentatie voor een deel.

[F.West98]

Met BikkelZ eens. Ik heb geen ervaring in grotere projecten BTW.

Over documentatie: ik schrijf nooit commentaar. Eigenlijk alleen als ik ineens denk 'hé, ik doe hier wat commentaar' en als de code echt moeilijk is. Dan zit het vol met commentaar.
Maar dat zijn eigen projectjes. Voor mijn werkgever doe ik het meestal achteraf, paar uurtjes voor uittrekken en commentaar zetten!

[Cor453]

F.West98 schreef op maandag 17 februari 2014 @ 00:06:
Met BikkelZ eens. Ik heb geen ervaring in grotere projecten BTW.

Over documentatie: ik schrijf nooit commentaar. Eigenlijk alleen als ik ineens denk 'hé, ik doe hier wat commentaar' en als de code echt moeilijk is. Dan zit het vol met commentaar.
Maar dat zijn eigen projectjes. Voor mijn werkgever doe ik het meestal achteraf, paar uurtjes voor uittrekken en commentaar zetten!

Waarbij ik mij toch even afvraag wat je collega's daar dan van vinden
Werk jij als enige aan bepaalde code? Hoeven je collega's het niet te snappen?

[F.West98]

Cor453 schreef op maandag 17 februari 2014 @ 00:10:
[...]


Waarbij ik mij toch even afvraag wat je collega's daar dan van vinden
Werk jij als enige aan bepaalde code? Hoeven je collega's het niet te snappen?

Tot nu toe enkel code waar ik zelf alleen aan werkte. Wel commentaar achteraf, zodat het nu wel begrijpbaar is.
Misschien in de toekomst een samenwerk-project, nu nog niet. (wel een class-library, en daar heb ik ook keurig specs gegeven bij de functies (hoe heette dat, dat het dan in je autocomplete verschijnt?))

[PrisonerOfPain]

Cor453 schreef op maandag 17 februari 2014 @ 00:10:
[...]


Waarbij ik mij toch even afvraag wat je collega's daar dan van vinden
Werk jij als enige aan bepaalde code? Hoeven je collega's het niet te snappen?

Ik schrijf ook nooit zo veel commentaar, en er zijn eigenlijk maar 4 momenten waarop ik als ik code lees graag commentaar wil zien eigenlijk, en dat zijn dan ook de plekken waar ik het probeer op te schrijven.

1. Threading context, dus regels over wie op welk moment aan welke variabelen mag zitten en wat bepaalde primitives beschermen.
2. Systeem regels. Kortom, welke objecten maken welke aannamens over lifetime, of momenten waarop dingen moeten gebeuren. Welke intentie had de designer met deze structuur?
3. Optimalisaties & complexe code. Al zie ik bij optimalisaties liever een stuk equivalente maar tragere code.
4. Links naar papers/ achtergrond informatie.

[Cor453]

PrisonerOfPain schreef op maandag 17 februari 2014 @ 00:19:
[...]


Ik schrijf ook nooit zo veel commentaar, en er zijn eigenlijk maar 4 momenten waarop ik als ik code lees graag commentaar wil zien eigenlijk, en dat zijn dan ook de plekken waar ik het probeer op te schrijven.

1. Threading context, dus regels over wie op welk moment aan welke variabelen mag zitten en wat bepaalde primitives beschermen.
2. Systeem regels. Kortom, welke objecten maken welke aannamens over lifetime, of momenten waarop dingen moeten gebeuren. Welke intentie had de designer met deze structuur?
3. Optimalisaties & complexe code. Al zie ik bij optimalisaties liever een stuk equivalente maar tragere code.
4. Links naar papers/ achtergrond informatie.

Okay, logisch. Ik schrijf eigenlijk alleen documentatie als ik het idee heb dat het niet compleet obvious is waarom iets gebeurt. Heel, heel vaak vind ik het geven van normale namen aan variabelen en functies veel belangrijker, omdat je dan snapt wat iets is en wat het roept.

Hoewel ik dat gedoe van bIsRectangle (b van boolean) of sName (s van string) echt compleet overtrokken vindt, maar dat ben ik. Is die programmeer-manier niet ook al compleet weggemieterd?

[BikkelZ]

Nou ik bedoel geen commentaar met documenteren maar zelfverklarende code, code die herkenbare patronen volgt, unit tests, juiste afhandeling van niet correcte input vanuit welke kant dan ook. Als ik jouw webservice consumeer en ik krijg alleen maar een vage nullpointerexception omdat achteraf gezien de derde parameter nooit hoger dan 100 had mogen zijn (maar dat deed het dynamische menuutje van jou toch niet) dan ben ik je vriend even niet meer.

Ik probeer echt commentaar in de trant van "ik zal het maar even uitleggen want deze code ziet er een beetje vaag uit" eigenlijk meer een aanleiding om de boel eventjes wat duidelijker te programmeren. Of tests er om heen die er uit klappen op het moment dat iemand iets er aan verandert.

[PrisonerOfPain]

BikkelZ schreef op maandag 17 februari 2014 @ 00:22:
Nou ik bedoel geen commentaar met documenteren maar zelfverklarende code, code die herkenbare patronen volgt, unit tests, juiste afhandeling van niet correcte input vanuit welke kant dan ook. Als ik jouw webservice consumeer en ik krijg alleen maar een vage nullpointerexception omdat achteraf gezien de derde parameter nooit hoger dan 100 had mogen zijn (maar dat deed het dynamische menuutje van jou toch niet) dan ben ik je vriend even niet meer.

Daar noem je een goed punt; 99% van de tijd kan ik gewoon zien wat de code die ik aanroep doet en hoe andere callsites de code aanroepen. Als je geen code hebt heb je inderdaad veel meer commentaar nodig.

[BikkelZ]

PrisonerOfPain schreef op maandag 17 februari 2014 @ 00:19:
[...]

• Optimalisaties & complexe code. Al zie ik bij optimalisaties liever een stuk equivalente maar tragere code.

Bij games ga je wel meer situaties met complexe geometrie krijgen die ook nog eens snel moet lopen, paar regeltjes commentaar kunnen dan geen kwaad. Zie wel eens wat code voorbij komen in games dat ik denk (maar dat ligt waarschijnlijk ook aan mijn ervaring).

Typische Enterprise / Business code gaat veel meer over het verplaatsen en aanpassen van gegevens uit het dagelijkse leven waarbij je je regels ook min of meer in "menselijke" taal kunt uitwerken.

[ Voor 16% gewijzigd door BikkelZ op 17-02-2014 00:26 ]

[Cor453]

/me Looks at BikkelZ sig...
/me Finds BikkelZ comments about coding standards completely relevant again...



Ik denk dat het werkveld zeker uitmaakt. Maar optimalisaties hoeven niet per definitie voor leesbaarheid te gaan vind ik.

[PrisonerOfPain]

BikkelZ schreef op maandag 17 februari 2014 @ 00:25:
[...]


Bij games ga je wel meer situaties met complexe geometrie krijgen die ook nog eens snel moet lopen, paar regeltjes commentaar kunnen dan geen kwaad. Zie wel eens wat code voorbij komen in games dat ik denk (maar dat ligt waarschijnlijk ook aan mijn ervaring).

Dat is over het algemeen een stukje vakkennis waar van mensen uitgaan tijdens het schrijven van die code.

[Cor453]

PrisonerOfPain schreef op maandag 17 februari 2014 @ 00:30:
[...]


Dat is over het algemeen een stukje vakkennis waar van mensen uitgaan tijdens het schrijven van die code.

En toch worden hele lappen code soms te snel of te onduidelijk geschreven, waarbij de eerste programmeur denkt dat ie het strak in mekaar heeft, en de volgende er geen chocolade meer van maakt. Where does that leave you?

[Styxxy]

F.West98 schreef op maandag 17 februari 2014 @ 00:14:
[...]
Tot nu toe enkel code waar ik zelf alleen aan werkte. Wel commentaar achteraf, zodat het nu wel begrijpbaar is.
Misschien in de toekomst een samenwerk-project, nu nog niet. (wel een class-library, en daar heb ik ook keurig specs gegeven bij de functies (hoe heette dat, dat het dan in je autocomplete verschijnt?))

XML Documentation Comments bedoel je waarschijnlijk.

[PrisonerOfPain]

Cor453 schreef op maandag 17 februari 2014 @ 00:32:
[...]


En toch worden hele lappen code soms te snel of te onduidelijk geschreven, waarbij de eerste programmeur denkt dat ie het strak in mekaar heeft, en de volgende er geen chocolade meer van maakt. Where does that leave you?

In perforce naar de change history kijken en een aantal van de laatste personen lastig vallen op Office Communicator / HipChat / email

[Patriot]

Firesphere schreef op zondag 16 februari 2014 @ 22:34:
[...]

Het is wel handig als je echt even shorthand nodig hebt en de boel compact wil houden. Ik gebruik het alleen als ik een bepaalde waarde uit een array wil hebben terwijl ik niet zeker weet of die wel bestaat.

PHP:

return (isset($array[$value])) ? $array[$value] : false;

Maar mooi is het zeker niet.

Ho, wacht, het ging niet om de ternary operator *op zich*, maar om het gebruiken van de ternary operator zonder de tweede expressie, dan krijg je zoiets:

PHP:

return $array[$value] ?: false;

Een volslagen nutteloze notatie als je iemand bent die er niet van houdt om dingen af te laten hangen van of iets al dan niet naar true evalueert.

[RayNbow]

BikkelZ schreef op zondag 16 februari 2014 @ 22:12:
[...]


Er is een uitbreiding op C# uitgekomen die volgens mij de hele reut in één regel kan, zoiets als ?? maar dan beter. Laat me even Googlen.

------

Aha, het heet Monadic Null checking http://damieng.com/blog/2...-6-0-features-illustrated

C#:

string GetZipCodeAsString(Person p)
{
    return person?.GetAddress()?.GetZipCode();
}

Het nadeel is alleen dat er dan speciale syntax moet worden ontworpen voor 1 specifieke use case in C#, terwijl de aanpak in bijv. Haskell een stuk algemener is.

Edit:

Caelorum schreef op zondag 16 februari 2014 @ 21:55:
Och, ik laat gewoon die null checks vaak zitten. Eerste persoon die code schrijft die een null in die functie probeert te stoppen krijgt een foutmelding van het systeem en mag zijn code herschrijven. Het is meer een gedachte/gewoonte dat null checks nodig zijn in C# dan dat het echt nodig is.

Zoals ik zei was het een overdreven voorbeeld met waar het maar kon een null-check.

Echter, je kunt nu wel zeggen dat je null inputs niet accepteert in je eigen functies (en dat is prima als precondition), maar wat doe je als een andere berekening mogelijk een null oplevert (als een geldige returnwaarde zoals gespecificeerd in de postcondition van de berekening)? Dan moet je wel op null controleren.

[ Voor 38% gewijzigd door RayNbow op 17-02-2014 07:10 ]

[Rutix]

PrisonerOfPain schreef op maandag 17 februari 2014 @ 00:42:
[...]


In perforce naar de change history kijken en een aantal van de laatste personen lastig vallen op Office Communicator / HipChat / email

Maar dat vergt ook altijd tijd . En je moet maar hopen dat de change history het goed omschreven heeft wat er is veranderd. Sommige mensen doen dit zeer goed maar ik kan ook mensen waar de commits echt super onzin zijn en er nog niks wijzer van word.

[Zoijar]

Rutix schreef op maandag 17 februari 2014 @ 08:24:
Maar dat vergt ook altijd tijd . En je moet maar hopen dat de change history het goed omschreven heeft wat er is veranderd. Sommige mensen doen dit zeer goed maar ik kan ook mensen waar de commits echt super onzin zijn en er nog niks wijzer van word.

Wij committen altijd onder jira ticket nummers, dan zie je meteen waarvoor de wijziging was en door wie.

[Cor453]

Mogguh! Koffie?

/me Slingert kan koffie de schuur in

[hylke94]

Cor453 schreef op maandag 17 februari 2014 @ 08:48:
Mogguh! Koffie?

/me Slingert kan koffie de schuur in

Ja, lekker. De automaat staat hier al weer zijn eerste kan koffie te maken .

[Rutix]

Zoijar schreef op maandag 17 februari 2014 @ 08:33:
[...]

Wij committen altijd onder jira ticket nummers, dan zie je meteen waarvoor de wijziging was en door wie.

Wij doen altijd onder TFS nummers maar dan nog als iemand of het work item niet goed bijhoudt of de commit niet duidelijk omschrijft is het niet altijd duidelijk waarom dat de fix was of waarom er voor is gekozen.

[Cor453]

/me Schenkt koffie voor Hylke94...

[Firesphere]

Mogguh

Koffie.

[D-Raven]

Mogguh.
Interesant artikel welke mij dit weekeind lekker bezig heeft gehouden:
http://0fps.net/2014/02/1...ed-games-overview-part-1/

[_Moe_]

Firesphere schreef op maandag 17 februari 2014 @ 09:09:
Mogguh

Koffie.

Morgen! Doe mij maar een tas.

[Cor453]

_Moe_ schreef op maandag 17 februari 2014 @ 09:20:
[...]


Morgen! Doe mij maar een tas.

Que pasa?

[Verwijderd]

Maandag

[Firesphere]

Tas is Belgisch voor kop/mok

[Cor453]

Firesphere schreef op maandag 17 februari 2014 @ 09:31:
Tas is Belgisch voor kop/mok

Weer wat geleerd vandaag

[PdeBie]

gisteren op NOS journaal een stuk over gameverslaving.
Was een jongen die 18 uur per dag speelde. Damn! Dan ben je inderdaad verslaafd.

[MoietyMe]

Iemand koffie?

[EddoH]

Ja, lekker.

Lol, wel een beetje treurig. Als het Programming forum open zie ik 4 topics waarvan 1 Coffe Corner, 1 gesloten, 1 zonder een enkele reply en 1 topic wat eigenlijk een grote discussie zonder einde is.

[DXaroth]

pdebie schreef op maandag 17 februari 2014 @ 09:35:
gisteren op NOS journaal een stuk over gameverslaving.
Was een jongen die 18 uur per dag speelde. Damn! Dan ben je inderdaad verslaafd.

maar 18 uur? damn, die gast slaapt te veel.

[Verwijderd]

pdebie schreef op maandag 17 februari 2014 @ 09:35:
gisteren op NOS journaal een stuk over gameverslaving.
Was een jongen die 18 uur per dag speelde. Damn! Dan ben je inderdaad verslaafd.

Ja, dat is echt triestig. Heb daar jaren geleden ook eens een "documentaire" over gezien. Moet je tijdens je middagpauze ook maar eens bekijken

[Rutix]

Wat ik dan altijd een beetje tegenstrijdig vind is dat ze vaak zeggen: "Ja ik was spel allang zat maar ik speelde nog steeds omdat ik main <x> was en mijn guild mates niet teleur wilde stellen". Ik snap dat wel maar toen ik speelde en minder wilde gaan spelen heb ik dat gewoon aangegeven en is er een vervanging voor mij gezocht (en die vind je best snel hoor). Maarja het is en blijft een moeilijke verslaving

[Ealanrian]

EddoH schreef op maandag 17 februari 2014 @ 09:36:
Ja, lekker.

Lol, wel een beetje treurig. Als het Programming forum open zie ik 4 topics waarvan 1 Coffe Corner, 1 gesloten, 1 zonder een enkele reply en 1 topic wat eigenlijk een grote discussie zonder einde is.

En direct 10 replys op het replyloze topic?

[StM]

Ik ben blij nooit aan WoW begonnen te zijn Ik heb er in de loop van de jaren verschillende gekend die naast WoW en school/werken eigenlijk niks dat ook maar iets wat op het hebben van een leven lijkt hadden... En vaak ging het op school/werk ook niet echt geweldig.

[Verwijderd]

StM schreef op maandag 17 februari 2014 @ 09:53:
Ik ben blij nooit aan WoW begonnen te zijn Ik heb er in de loop van de jaren verschillende gekend die naast WoW en school/werken eigenlijk niks dat ook maar iets wat op het hebben van een leven lijkt hadden... En vaak ging het op school/werk ook niet echt geweldig.

Heb je echt nieuwsberichten nodig om die conclusies te kunnen trekken?

[Cor453]

@GuidoH over het algemeen weten mensen dat wel, maar het is maar een aanleiding waardoor je er weer bij bepaald wordt.

[Verwijderd]

StM schreef op maandag 17 februari 2014 @ 09:53:
Ik ben blij nooit aan WoW begonnen te zijn Ik heb er in de loop van de jaren verschillende gekend die naast WoW en school/werken eigenlijk niks dat ook maar iets wat op het hebben van een leven lijkt hadden... En vaak ging het op school/werk ook niet echt geweldig.

Ik heb het vroeger wel even gespeeld en vond het best fijn. Ik moet zeggen dat ik dit echter wel met mate wist te doen. Ik speelde slechts een paar uur per dag (max 4) en was er eigenlijk niet echt competitief mee bezig. Ik speelde voornamelijk voor de lol en zat ook niet altijd in een guild.

[StM]

Verwijderd schreef op maandag 17 februari 2014 @ 09:54:
[...]

Heb je echt nieuwsberichten nodig om die conclusies te kunnen trekken?

Nee hoor, die overtuiging heb ik al een jaartje of 8-10 (Of hoe oud is WoW)

[EddoH]

Ealanrian schreef op maandag 17 februari 2014 @ 09:47:
[...]

En direct 10 replys op het replyloze topic?

Eh. nee 1 nu?

[Cor453]

Tis sowieso de laatste tijd niet echt druk in PRG ofzo...

[Verwijderd]

Cor453 schreef op maandag 17 februari 2014 @ 10:04:
Tis sowieso de laatste tijd niet echt druk in PRG ofzo...

Ik skip al jaren het PRG-overzicht. Devschuur is enige topic waar ik kom. Voor serieuzere dingen ga ik wel naar StackOverflow.

[Cor453]

Verwijderd schreef op maandag 17 februari 2014 @ 10:07:
[...]

Ik skip al jaren het PRG-overzicht. Devschuur is enige topic waar ik kom. Voor serieuzere dingen ga ik wel naar StackOverflow.

Ik vind sowieso het niveau van het forum laag de laatste tijd, maar dat is mijn mening. Niet om weer eeuwige discussies op te laten laaien, maar het feit dat PRG leeg is betekent volgens mij gewoon dat er weinig meer echte Software-IT-pro's komen. Of ben ik echt een uitzondering als ik dat denk...

Btw, ik vind SO ook niet altijd even hoog van niveau. Sommige antwoorden worden de hemel in geprezen, terwijl ze gewoon bagger zijn...

[Verwijderd]

Cor453 schreef op maandag 17 februari 2014 @ 10:12:
[...]


Ik vind sowieso het niveau van het forum laag de laatste tijd, maar dat is mijn mening. Niet om weer eeuwige discussies op te laten laaien, maar het feit dat PRG leeg is betekent volgens mij gewoon dat er weinig meer echte Software-IT-pro's komen. Of ben ik echt een uitzondering als ik dat denk...

Dat is exact de reden waarom ik er niet meer kom. Ik zal geen specifieke topics noemen, maar als ik even blader door het PRG-overzicht, wordt mijn blik hierop wederom bevestigd.

Btw, ik vind SO ook niet altijd even hoog van niveau. Sommige antwoorden worden de hemel in geprezen, terwijl ze gewoon bagger zijn...

Moet zeggen dat ik het over het algemeen wel redelijk tevreden ben met het niveau op StackOverflow. Er zullen zo hier en daar wel eens verkeerde antwoorden tussen zitten die geaccepteerd worden, maar over het algemeen wordt dat toch wel goed opgepakt door de gebruikers.

[Cor453]

Verwijderd schreef op maandag 17 februari 2014 @ 10:17:
[...]

Moet zeggen dat ik het over het algemeen wel redelijk tevreden ben met het niveau op StackOverflow. Er zullen zo hier en daar wel eens verkeerde antwoorden tussen zitten die geaccepteerd worden, maar over het algemeen wordt dat toch wel goed opgepakt door de gebruikers.

Ligt er misschien ook een beetje aan welke taal je doet. Ik klop veel Objective-C en vind de antwoorden niet altijd even goed of duidelijk. Ik merk bijv. bij C# dat dit al weer veel beter is.

[Verwijderd]

Cor453 schreef op maandag 17 februari 2014 @ 10:12:
[...]


Ik vind sowieso het niveau van het forum laag de laatste tijd, maar dat is mijn mening. Niet om weer eeuwige discussies op te laten laaien, maar het feit dat PRG leeg is betekent volgens mij gewoon dat er weinig meer echte Software-IT-pro's komen. Of ben ik echt een uitzondering als ik dat denk...

Btw, ik vind SO ook niet altijd even hoog van niveau. Sommige antwoorden worden de hemel in geprezen, terwijl ze gewoon bagger zijn...

Het is een vicieuze cirkel he: er zitten te weinig programmeurs op GoT omdat er te weinig (goede) programmeurs op GoT zitten.

Als ik een topic van bijvoorbeeld .oisyn voorbij zie komen, moet ik ergens in het midden van de TS afhaken omdat ik gewoon geen flauw idee heb over wat het gaat. Simpele vragen in verband met PHP, Java of C#, willen me wel nog eens lukken maar ook ik kijk niet echt vaak in /PRG (buiten dit topic dan)

[Verwijderd]

Cor453 schreef op maandag 17 februari 2014 @ 10:20:
[...]


Ligt er misschien ook een beetje aan welke taal je doet. Ik klop veel Objective-C en vind de antwoorden niet altijd even goed of duidelijk. Ik merk bijv. bij C# dat dit al weer veel beter is.

Ik gebruik StackOverflow ook het meest voor Objective-C, en heb weinig te klagen over antwoorden. Heb je toevallig specifieke voorbeelden?

[OkkE]

Langzaam aan voorbereidingen treffen voor mijn vakantie over 2 weken; deze week planning maken, alvast wat taken overdragen, etc. Vooral niet erg om een paar van de vervelende taken (met deadline in mijn vakantie) te kunnen “afschuiven”.

[Verwijderd]

quote: https://twitter.com/PHP_CEO/status/435105782829305857

IT HAS COME TO MY ATTENTION THAT SOMEONE CALLED JASON HAS BEEN ENCODING AND DECODING DATA IN OUR APP. PLEASE CHANGE YOUR PASSWORDS

[PdeBie]

Verwijderd schreef op maandag 17 februari 2014 @ 09:41:
[...]


Ja, dat is echt triestig. Heb daar jaren geleden ook eens een "documentaire" over gezien. Moet je tijdens je middagpauze ook maar eens bekijken
[video]

top, ga ik in de pauze even kijken

[Douweegbertje]

Verwijderd schreef op maandag 17 februari 2014 @ 10:17:
[...]

Dat is exact de reden waarom ik er niet meer kom. Ik zal geen specifieke topics noemen, maar als ik even blader door het PRG-overzicht, wordt mijn blik hierop wederom bevestigd.

[...]

Moet zeggen dat ik het over het algemeen wel redelijk tevreden ben met het niveau op StackOverflow. Er zullen zo hier en daar wel eens verkeerde antwoorden tussen zitten die geaccepteerd worden, maar over het algemeen wordt dat toch wel goed opgepakt door de gebruikers.

Wel een beetje jammer dat je zelf alles prima weet, maar dan niet je kennis deelt. Just saying. Verhoog het niveau dan eens door wat briljantst te typen

[Caelorum]

RayNbow schreef op maandag 17 februari 2014 @ 05:59:
[...] Echter, je kunt nu wel zeggen dat je null inputs niet accepteert in je eigen functies (en dat is prima als precondition), maar wat doe je als een andere berekening mogelijk een null oplevert (als een geldige returnwaarde zoals gespecificeerd in de postcondition van de berekening)? Dan moet je wel op null controleren.

Zoals ik al zei, ik accepteer het zelf niet en doe zo min mogelijk null checks. Als het nodig is wel, maar ik zie zo vaak code langskomen waar echt overal null checks wordt gedaan. Compleet overbodig. Zelfs bij framework functies is het niet altijd nodig.

Verwijderd schreef op maandag 17 februari 2014 @ 10:21:
[...]
Als ik een topic van bijvoorbeeld .oisyn voorbij zie komen, moet ik ergens in het midden van de TS afhaken omdat ik gewoon geen flauw idee heb over wat het gaat. [...]

Tja, ik heb nooit echt het idee dat er te weinig programmeurs hier rondlopen, en een topic van .oisyn laat altijd ook wel zien dat het gemiddelde niveau ook nog wel redelijk hoog ligt. Het is gewoon een grote stap om hier een topic te openen en daardoor lijkt het 'leeg' te zijn. Je ziet eigenlijk veel nieuwkomers die topics openen, omdat ze niet bekend zijn met het forum en dus niet 'weten' dat de drempel redelijk hoog ligt. Daarnaast denk ik dat velen hier ook wel behoorlijk wat met zelf zoeken te weten komen en daardoor eigenlijk helemaal geen topic hoeven te openen hier.
Vind die topics van .oisyn e.d. wel altijd leuk, maar moet vaak ook halverwege afhaken of heb ik gewoon geen nuttige inbreng.

[Hoogie2004]

Verwijderd schreef op maandag 17 februari 2014 @ 10:31:
[...]
IT HAS COME TO MY ATTENTION THAT SOMEONE CALLED JASON HAS BEEN ENCODING AND DECODING DATA IN OUR APP. PLEASE CHANGE YOUR PASSWORDS

Briljant

Hij heeft er ook die voelen alsof het over hier gaat

THE DEVELOPERS LOVE IT WHEN I ADD NEW FEATURES IN THE MIDDLE OF THE NIGHT. IT’S LIKE CHRISTMAS MORNING WHEN THEY FIND OUT! PANDEMONIUM!

[Alex)]

Een nieuwe maandagmorgen, een nieuwe gelegenheid voor WTFs. Dit keer de registratiewebsite van een bepaalde vendor. Om wat documentatie te kunnen lezen en dingen te kunnen downloaden moest ik een account hebben (so far so good).

Het ontvangen van het activatiemailtje voor het account duurde anderhalve dag i.p.v. de beloofde "maximaal 2 uur". Daarna moet ik eerst mijn wachtwoord wijzigen, met de volgende aardig bizarre requirements:

Your password must

Be exactly 8 characters long
Include at least one letter (a-z, A-Z) and one number (0-9). Note: the password is not case-sensitive
Include at least one special character from the following set: ! \ " @ $ % & / ( { [ ] } ) + - * = ? ' ~ # _ . , ; : < >
Not contain any blanks
Not start with ? or !
Not begin with 3 identical characters
Be different from the last 5 passwords

[Verwijderd]

Douweegbertje schreef op maandag 17 februari 2014 @ 10:33:
[...]


Wel een beetje jammer dat je zelf alles prima weet, maar dan niet je kennis deelt. Just saying. Verhoog het niveau dan eens door wat briljantst te typen

Daarvoor kom ik niet voor op GoT. Vind het wel prima zo.

[Verwijderd]

Caelorum schreef op maandag 17 februari 2014 @ 10:33:

[...]

Tja, ik heb nooit echt het idee dat er te weinig programmeurs hier rondlopen, en een topic van .oisyn laat altijd ook wel zien dat het gemiddelde niveau ook nog wel redelijk hoog ligt. Het is gewoon een grote stap om hier een topic te openen en daardoor lijkt het 'leeg' te zijn. Je ziet eigenlijk veel nieuwkomers die topics openen, omdat ze niet bekend zijn met het forum en dus niet 'weten' dat de drempel redelijk hoog ligt. Daarnaast denk ik dat velen hier ook wel behoorlijk wat met zelf zoeken te weten komen en daardoor eigenlijk helemaal geen topic hoeven te openen hier.
Vind die topics van .oisyn e.d. wel altijd leuk, maar moet vaak ook halverwege afhaken of heb ik gewoon geen nuttige inbreng.

Daar haal je inderdaad een interessant punt aan. Een van de grote verschillen tussen GoT en SO, is dat er hier meer moeite wordt gedaan voor er een topic wordt geopend. Op SO vind je de ene achter de andere vraag die gewoon door 2 minuten Googlen wel te beantwoorden zou zijn.

Topics op GoT worden zomaar gesloten als er niet genoeg tijd / moeite in je TS is gekropen en dat vind ik prima. Het houdt het niveau over het algemeen op een leuk pijl. Soms start ik met het schrijven van een TS waarin ik stap per stap uitleg wat ik zelf al geprobeerd heb en waar het probleem zit waardoor ik dan uit het niets ineens een ingeving krijg. Zowat hetzelfde principe als "rubber duck debugging".

[Verwijderd]

Verwijderd schreef op maandag 17 februari 2014 @ 10:44:
[...]


Daar haal je inderdaad een interessant punt aan. Een van de grote verschillen tussen GoT en SO, is dat er hier meer moeite wordt gedaan voor er een topic wordt geopend. Op SO vind je de ene achter de andere vraag die gewoon door 2 minuten Googlen wel te beantwoorden zou zijn.

De meeste vragen die ik heb zijn prima te Googlen. Alleen kom ik dan 9 v/d 10 keer uit op StackOverflow.

Topics op GoT worden zomaar gesloten als er niet genoeg tijd / moeite in je TS is gekropen en dat vind ik prima. Het houdt het niveau over het algemeen op een leuk pijl. Soms start ik met het schrijven van een TS waarin ik stap per stap uitleg wat ik zelf al geprobeerd heb en waar het probleem zit waardoor ik dan uit het niets ineens een ingeving krijg. Zowat hetzelfde principe als "rubber duck debugging".

Dat heb ik ook vaak, beschrijven wat je probleem is en wat je al geprobeerd hebt is soms al genoeg.

[Alex)]

Error Message - No download authorization

Krijg de v**********g, vendor. Ik haat je.

[Ealanrian]

Verwijderd schreef op maandag 17 februari 2014 @ 10:48:
[...]

De meeste vragen die ik heb zijn prima te Googlen. Alleen kom ik dan 9 v/d 10 keer uit op StackOverflow.


[...]

Dat heb ik ook vaak, beschrijven wat je probleem is en wat je al geprobeerd hebt is soms al genoeg.

En in beide punten zit dus ook de reden waarom er hier minder topics zijn denk ik.

[Alex)]

On the plus side, licentie voor ReSharper 8.0 is binnen.

[Cor453]

Mijn wens voor 2014: laat browsermakers de user agent strings gewoon eens eerlijk houden. Dat gedoe van "ik ben eigenlijk IE, maar ik doe mij ook voor als een Firefox browser. En misschien, als je heel naïef bent, lijk ik voor jou wel op Google Chrome".

Om over mobiele browsers nog maar te zwijgen... http://www.useragentstring.com/pages/Mobile%20Browserlist/

[TheNephilim]

Zo, na een hele week ziek eindelijk weer terug op kantoor

[Verwijderd]

Cor453 schreef op maandag 17 februari 2014 @ 10:59:
Mijn wens voor 2014: laat browsermakers de user agent strings gewoon eens eerlijk houden. Dat gedoe van "ik ben eigenlijk IE, maar ik doe mij ook voor als een Firefox browser. En misschien, als je heel naïef bent, lijk ik voor jou wel op Google Chrome".

Om over mobiele browsers nog maar te zwijgen... http://www.useragentstring.com/pages/Mobile%20Browserlist/

Ik weet niet meer waar ik het precies las, maar Opera zou tegenwoordig echt een pareltje van een user agent string hebben.

Edit: Op GoT dus: dcm360 in "De Devschuur Coffee Corner - Iteratie 5"

[ Voor 7% gewijzigd door Verwijderd op 17-02-2014 11:03 ]

[Cor453]

Verwijderd schreef op maandag 17 februari 2014 @ 11:02:
[...]


Ik weet niet meer waar ik het precies las, maar Opera zou tegenwoordig echt een pareltje van een user agent string hebben.

Bedoel je dat als "zo die zijn creatief" of van "dit is bijzonder consequent"...

[Verwijderd]

Cor453 schreef op maandag 17 februari 2014 @ 11:03:
[...]


Bedoel je dat als "zo die zijn creatief" of van "dit is bijzonder consequent"...

Zie edit

[Cor453]

Oke... dat is dus echt huilen. Ik probeer nu een beetje op een normale manier User Agents te categoriseren, maar de regexen die daarvoor beschikbaar zijn zijn schrikbarend lang of bijzonder log/onwerkbaar.

Ik wil normale user agents!
/me Schopt tegen tafel, gooit Macbook uit raam
Zo.

[Firesphere]

Er zijn toch genoeg regexjes voor te vinden die alle useragents onderschijt?

[Verwijderd]

Firesphere schreef op maandag 17 februari 2014 @ 11:08:
Er zijn toch genoeg regexjes voor te vinden die alle useragents onderschijt?

Useragents onderschijten heb ik geen regex voor nodig hoor, hooguit een WC-pot.

[BtM909]

Cor453 schreef op maandag 17 februari 2014 @ 11:05:
Oke... dat is dus echt huilen. Ik probeer nu een beetje op een normale manier User Agents te categoriseren, maar de regexen die daarvoor beschikbaar zijn zijn schrikbarend lang of bijzonder log/onwerkbaar.

Waarom zou je User Agents willen catelogiseren En ga je daarbij ook alle custom ones meenemen?

[wouterwouter2]

BtM909 schreef op maandag 17 februari 2014 @ 11:11:
[...]

Waarom zou je User Agents willen catelogiseren En ga je daarbij ook alle custom ones meenemen?

Inderdaad. Ik weet je probleem niet maar je aanpak is al fout. Met User Agent detection loop je altijd achter, je moet zelf handmatig de lijst updaten (wat alleen kan als een nieuwe device uit is), je moet je lijst dan categoriseren in mobiel, tablet, desktop, etc. En daarnaast weet je niet of een gebruiker met een tablet wel een tablet geoptimaliseerde website wilt zien.

Je kunt beter kijken naar andere oplossingen zoals, Feature Detection, Progressive Enhancement / Graceful Degradation, Media Queries, of iets anders waarmee je je probleem kunt oplossen.

[Cor453]

BtM909 schreef op maandag 17 februari 2014 @ 11:11:
[...]

Waarom zou je User Agents willen catelogiseren En ga je daarbij ook alle custom ones meenemen?

Echt alles categoriseren is een groot woord. Het gaat mij erom dat ik op een redelijk foutongevoelige manier server-side checks kan doen op User Agents. En nu snap ik best dat er allemaal regexen zijn en manieren om het te fixen, maar ik wordt gewoon spontaan verdrietig als ik er al een minuut naar kijk. Het hele user agent principe is gewoon een gedrocht.

Nu heb ik wel een manier gevonden die goed werkt, maar het frustreert me gewoon. Waarom moeten al die browsermakers doen alsof ze iemand anders zijn... (Retorische vraag he )

@Wouterwouter2: jij weet op voorhand dat mijn implementatie fout is maak dan even een goeie aub

[ Voor 6% gewijzigd door Cor453 op 17-02-2014 11:19 ]

[OkkE]

Cor453 schreef op maandag 17 februari 2014 @ 11:17:
Echt alles categoriseren is een groot woord. Het gaat mij erom dat ik op een redelijk foutongevoelige manier server-side checks kan doen op User Agents.[...]

Maar waarom wil je dit? Waar heb je die info op de server voor nodig?