[alg] Slechtste programmeervoorbeelden deel 4

[R4gnax]

Noxious schreef op donderdag 28 april 2011 @ 13:09:
Hoe slecht is mijn helper class? Ik heb vernomen dat 'ie ranzig is

C#:

namespace TSMServiceHelper
{
    static class TsmLogic
    {
        public static double GetUnixTime()
        {
            var ts = DateTime.UtcNow - new DateTime(1970, 1, 1, 0, 0, 0);
            return Math.Round(ts.TotalSeconds);
        }
        public static string StripSlashes(string input)
        {
            return System.Text.RegularExpressions.Regex.Replace(input, @"(\\)([\000\010\011\012\015\032\042\047\134\140])", "$2");
        }
    }
}

Slecht, want het gooit gewoon een aantal ongerelateerde functionaliteiten op één hoop. In het geval van de Unix time conversie vergeet je trouwens ook de Unix epoch in UTC aan te maken. In plaats daarvan krijgt deze dan DateTimeKind.Unspecified toegekend. Het werkt gelukkig wel, omdat DateTime.Subtract de DateTimeKind en DateTimeOffset (tijdzone) negeert, maar het is absoluut niet netjes. Verder heb ik wat vraagtekens bij het gebruik van Math.Round voor het afronden. Ik zou in het geval van tijd in seconden eerder met Math.Floor werken.

Voor een algemene Unix time conversie schrijf je beter een simpele extension method, zoals het volgende:

C#:

[EditorBrowsable(EditorBrowsableState.Never)]
public static class DateTimeExtensions
{
  private readonly DateTime unixEpoch = new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc);

  public static long ToUnixTime(this DateTime source)
  {
    return (long)Math.Floor(source.ToUniversalTime().Subtract(unixEpoch).TotalSeconds);
  }
}

(Let trouwens wel dat zo'n naïve conversie eigenlijk altijd onnauwkeurig is, want er wordt geen rekening gehouden met de leap seconds die UTC bevat.)


Wat betreft het strippen van slashes is er wat meer context nodig. Waarvoor wordt het gebruikt?
(Waarom is de regex trouwens niet pre-compiled?)

[roy-t]

Extension methods zijn super handig, maar ik weet nooit waar ik ze moet laten, ik gebruik de volgende opties door elkaar.

-In dezelfde .cs file waar ik de extensionmethod nodig had
-In een appart Utilities.cs
-In ClassName.Extensions.cs


Wat doen jullie?

[Alex)]

In een aparte namespace: <project>.Extensions (en dus ook een aparte folder op het filesystem)

En dan daarin weer meerdere classes zodat de extension methods gegroepeerd zijn op functionaliteit (SPListExtensions, SPWebExtensions, DateTimeExtensions, enz).

[MatHack]

In de <project>.Common assembly, in de namespace <project>. Hier staan ook andere veelgebruikte constants, enumerations, methods, etc. in.

Vaak heb ik voldoende aan een ExtensionMethods.cs met daarin regions per Type.
Anders zou ik ze ook opdelen zoals Alex) al aangeeft, in een aparte folder ExtensionMethods (binnen <project>.Common) met filenames die duidelijk aangeven voor welk Type de extension methods zijn.

[Verwijderd]

TheCoolGamer schreef op zaterdag 30 april 2011 @ 23:57:

PHP:

${$_GET['var']} = true

is net zo gevaarlijk als

PHP:

include $_GET['var'];

Dus als je gebruikersinput direct gebruikt als variabelenaam dan levert dat inderdaad een beveiligingsprobleem op. Maar ja, dat is natuurlijk altijd een risico: gebruikersinput ongecontroleerd overal voor gebruiken.

Ja, dus? Als iemand zoiets gebruikt, dan is het zijn fout dat het niet goed werkt en zo lek als een mandje is, dat ligt niet aan de taal.

Edit:
Als je een taal niet goed kent, en niet weet wat je doet. Dan krijg je soms wel eens leuke dingen, vooral erg leuk als je er achter komt wat je nou eigenlijk doet... Voorbeeldje in Objective-C:

code:

[[item retain] release];

Da's wel aardig slecht...

[ Voor 19% gewijzigd door Verwijderd op 02-05-2011 20:19 ]

[Matis]

WUT

[eBoR]

je hoeft niet bang te zijn dat je je internet bundel opkrijgt

[mithras]

Dat lijkt me redelijk zorgeloos

[Alex)]

Volgens mij zijn ze bezig:

[YopY]

Verwijderd schreef op zondag 01 mei 2011 @ 18:03:
[...]

Ja, dus? Als iemand zoiets gebruikt, dan is het zijn fout dat het niet goed werkt en zo lek als een mandje is, dat ligt niet aan de taal.

Edit:
Als je een taal niet goed kent, en niet weet wat je doet.

On that note, groot deel van lekheid ligt hem helemaal niet aan de taal, maar aan de library en de rest van de 'stack' (om het zo maar eens te noemen), danwel de omgeving waar het in gebruikt wordt ende de tools die je ermee aanroept. Een "echo ' OR 1 == 1' --" kan echt geen kwaad, of een "alert(document.cookie)" ook niet zolang je het niet in een browser doet.

sdfa - de taal de schuld geven kun je eigenlijk alleen in low-level talen zoals C en companen doen, waar je buffer overflows en dat soort grapjes kunt doen. De rest zit hem in de 'stdlib' (in het geval van PHP) en verkeerd gebruik daarvan.

Willekeurige half-12-rant, negeren plx anders schaam ik me er morgenochtend weer voor .

[Matis]

Alex) schreef op maandag 02 mei 2011 @ 23:14:
Volgens mij zijn ze bezig:

[afbeelding]

Bij mij hebben ze het nog steeds niet gefixt.

1048576,00 MB

Daarnaast is er niets af, terwijl dit zeker wel zou moeten (bijwerkdatum is ook bijgewerkt).

Misschien komt dit nog omdat ik nog van de oude stempel ben en ik mijn internet blox afsloot, toen het nog echt onbeperkt was.
Volgens mij heb je vanaf nu 250MB bij de 100minuten-variant en 1000MB bij de 150-of-groter-variant.

[Alex)]

Als ik nu inlog zie ik staan dat ik nog 1024 MB tegoed heb voor "Zorgeloos Web", terwijl ik een abo met een FUP heb. Die meter ga ik dus in de gaten houden.

[Alex)]

Kwam zojuist dit tegen:

C#:

var sb = new StringBuilder();

int count = 0;
foreach (string s in Parameters)
{
    sb.Append(s);
    if (count < (Parameters.Count - 1))
    {
        sb.Append(", ");
    }
    else
    {
        sb.Append(" ");
    }
    count++;
}

Vervangen door:

C#:

var query = string.Join(", ", Parameters.ToArray()) + " ";

Veel mooier imo.

[.Gertjan.]

Alex) schreef op dinsdag 03 mei 2011 @ 14:57:
Kwam zojuist dit tegen:

C#:

var sb = new StringBuilder();

int count = 0;
foreach (string s in Parameters)
{
    sb.Append(s);
    if (count < (Parameters.Count - 1))
    {
        sb.Append(", ");
    }
    else
    {
        sb.Append(" ");
    }
    count++;
}

Vervangen door:

C#:

var query = string.Join(", ", Parameters.ToArray()) + " ";

Veel mooier imo.

Nog mooier als je geen var gebruikt
Nu kun je in jouw geval nog wel verzinnen wat het type van de var is, maar stel dat het uit een functie komt wordt het een stuk minder logisch.

Ja, intellisense weet het allemaal wel, maar het is niet altijd handig om intellisense te moeten gebruiken. Soms lees je code ook wel eens buiten visual studio terug...

[Alex)]

Niks mis met var in deze situatie. Of wil je zeggen dat

C#:

StringBuilder stringBuilder = new StringBuilder();

nou zo veel duidelijker is?

Bij dingen die uit een method gehaald worden is het wisselend, als de naam van de method omschrijvend genoeg is gebruik ik daar ook gewoon var. Anders niet.

[ Voor 35% gewijzigd door Alex) op 03-05-2011 15:12 ]

[.Gertjan.]

Alex) schreef op dinsdag 03 mei 2011 @ 15:12:
Niks mis met var in deze situatie. Of wil je zeggen dat

C#:

StringBuilder stringBuilder = new StringBuilder();

nou zo veel duidelijker is?

Bij dingen die uit een method gehaald worden is het wisselend, als de naam van de method omschrijvend genoeg is gebruik ik daar ook gewoon var. Anders niet.

Zoals gezegd is het in dit geval niet echt een probleem.

Maar wanneer het vanuit een ander plekje komt:

C#:

//Uiteraard is .Function().Function()....enz... niet echt mooie code, maar goed.
var output = Class.Function().Function().Function();

is het ineens een stukje minder duidelijk. In dat geval is het aangeven wat het type van de var is toch echt wel duidelijker i.m.o.. Daarnaast heette je variabele in je eerste voorbeeld sb en niet stringBuilder.

Edit: n.a.v. je edit. Dan is het goed, maar sommige mensen hebben var-diaree en smijten het liefst overal een var neer

[ Voor 6% gewijzigd door .Gertjan. op 03-05-2011 15:18 ]

[Alex)]

"sb" vind ik persoonlijk ook onduidelijker dan "stringBuilder", bij zo'n onduidelijke naam maakt die var ook niet meer uit. Ik ben het in zoverre met je eens dat in het voorbeeld dat je schetst var geen duidelijkheid schept, maar een strongly typed object geeft ook geen duidelijkheid.

Wat nou als die Function() object als returntype heeft?

[BasieP]

Alex) schreef op dinsdag 03 mei 2011 @ 15:25:
"sb" vind ik persoonlijk ook onduidelijker dan "stringBuilder", bij zo'n onduidelijke naam maakt die var ook niet meer uit. Ik ben het in zoverre met je eens dat in het voorbeeld dat je schetst var geen duidelijkheid schept, maar een strongly typed object geeft ook geen duidelijkheid.

Wat nou als die Function() object als returntype heeft?

tja de 'var' discussie is al een paar keer voorbij gekomen, en imo is het redelijk vanzelf sprekend wanneer je hem wel kunt gebruiken en wanneer niet.

Tuurlijk heeft iedereen zo z'n voorkeur. Net als

C#:

if (condition)
{
  //do stuff
}

vs

C#:

if (conditon)
    //do stuff

ikzelf heb wel eens dit soort code moeten wijzigen:

C#:

Dictionairy<Guid, List<string, List<CustomObject>>> dicItemList = new Dictionairy<Guid, List<string, List<CustomObject>>>();

dan is var wel handig

[ Voor 12% gewijzigd door BasieP op 03-05-2011 15:32 ]

[Verwijderd]

Ik kies dan toch echt voor:

C#:

if (condition) { 
  //do stuff 
}

[BasieP]

Verwijderd schreef op dinsdag 03 mei 2011 @ 15:31:
Ik kies dan toch echt voor:

C#:

if (condition) { 
  //do stuff 
}

die door je visual studio wordt aangepast naar:

C#:

if (condition) 
{ 
  //do stuff 
}

(ja tenzij je standaard settings aanpast, maar dat raad ik helemaal af)

[ Voor 11% gewijzigd door BasieP op 03-05-2011 15:33 ]

[Sebazzz]

BasieP schreef op dinsdag 03 mei 2011 @ 15:33:
[...]

(ja tenzij je standaard settings aanpast, maar dat raad ik helemaal af)

Hoezo?

Ik vind braces op dezelfde lijn juist fijner werken. Smaak enzo? Zolang je maar consequent bent.

[.Gertjan.]

Sebazzz schreef op dinsdag 03 mei 2011 @ 15:36:
[...]

Hoezo?

Ik vind braces op dezelfde lijn juist fijner werken. Smaak enzo? Zolang je maar consequent bent.

Moet je eens in de codebase van Dynamics Axapta kijken... Microsoft heeft een mooi lijstje met coding practices opgesteld maar houden zichzelf er totaal niet aan. Zelfs code gegenereerd door de meegeleverde templates schendt alle voorwaardes.

Zo hoort iedere variabele die een functie in gaat met een underscore te beginnen (zo schrijft men het voor), maar als je een property laat genereren zet Axapta ze er zelf niet voor...

Als je de code in AX compilet met de best practice levels op maximaal trekt de compiler het niet meer, zo ontzettend veel "fouten" zitten er al in het standaard pakket

Markant punt is overigens dat je als MS partner wordt afgerekend op dit soort zaken als er geaudit wordt...

[kenneth]

Enige 'echte' argument dat ik ken is dat je bij het debuggen de conditie makkelijk uit kan commenten:

C#:

// if (condition) 
{ 
  //do stuff 
}

Enige reden dat wij het doen is dat het de standaardinstelling is

[BasieP]

Sebazzz schreef op dinsdag 03 mei 2011 @ 15:36:
[...]

Hoezo?

Ik vind braces op dezelfde lijn juist fijner werken. Smaak enzo? Zolang je maar consequent bent.

er is niets mis met braces, maar wel beide op een eigen regel. Niet zozeer omdat dit beter is, maar omdat je anders de standaard visual studio instellingen aanpast, en wanneer je daaraan begint is teamwork direct 'a thing of the past'

nogmaals, ieder z'n eigen smaak, en het weglaten van braces (voor 1 regel na een if-statement of loop) of het plaatsen van braces valt beide onder de standaard instellingen.

kenneth schreef op dinsdag 03 mei 2011 @ 15:41:

Enige reden dat wij het doen is dat het de standaardinstelling is

het is helemaal geen standaardinstelling... sterker nog: het is geen instelling
(behalve misschien bij code generatie, maar zo vaak doe je dat niet)

[ Voor 20% gewijzigd door BasieP op 03-05-2011 15:44 ]

[Matis]

kenneth schreef op dinsdag 03 mei 2011 @ 15:41:
Enige 'echte' argument dat ik ken is dat je bij het debuggen de conditie makkelijk uit kan commenten:

C#:

// if (condition) 
{ 
  //do stuff 
}

Enige reden dat wij het doen is dat het de standaardinstelling is

Waarom geen preprocessor-blok er omheen?

[kenneth]

BasieP schreef op dinsdag 03 mei 2011 @ 15:43:
[...]

er is niets mis met braces, maar wel beide op een eigen regel. Niet zozeer omdat dit beter is, maar omdat je anders de standaard visual studio instellingen aanpast, en wanneer je daaraan begint is teamwork direct 'a thing of the past'

nogmaals, ieder z'n eigen smaak, en het weglaten van braces (voor 1 regel na een if-statement of loop) of het plaatsen van braces valt beide onder de standaard instellingen.

[...]


het is helemaal geen standaardinstelling... sterker nog: het is geen instelling
(behalve misschien bij code generatie, maar zo vaak doe je dat niet)

Eh Eerst zeg je dat je het niet moet veranderen omdat je de instellingen daarvoor aanpast, daarna reageer je op mijn post met de opmerking dat het geen instelling is?

Matis schreef op dinsdag 03 mei 2011 @ 15:45:
[...]

Waarom geen preprocessor-blok er omheen?

Twee slashes typt sneller.
Ik doe het zelf nooit zo maar dat is het enige argument dat ik hoor dat enigszins steekhoudend is.

[.Gertjan.]

BasieP schreef op dinsdag 03 mei 2011 @ 15:43:
[...]

er is niets mis met braces, maar wel beide op een eigen regel. Niet zozeer omdat dit beter is, maar omdat je anders de standaard visual studio instellingen aanpast, en wanneer je daaraan begint is teamwork direct 'a thing of the past'

Och, als het hele team het zelfde doet is er niets aan de hand. Het eerste wat bij mij om gaat in VS is het gebruik van "echte tabs", omdat ik een grafhekel aan spaties hebt (zeker als je buiten VS ook wel eens aan je bestanden zit).

Dit soort dingen neem je op in je coding guidelines en daar heeft men zich maar gewoon aan te houden. Pipo's die de guidelines schenden worden gekruisigd aangesproken.

[Alex)]

Mijn voorkeur is om braces op een eigen regel te hebben, zodat ik snel kan zien welke braces bij elkaar horen. Werk ik in andermans code (in Visual Studio) waarbij de braces of indenting niet klopt, doe ik een snelle Ctrl+K Ctrl+D en klopt alles weer.

[Matis]

Onze coding style (Misra C) schrijft voor dat // niet mag als commentaar, alleen /* */ is toegestaan, mits er geen nesting in voorkomt
Daarnaast heb ik vaak een define TESTVECTOR welke dus een preprocessor-blok drived.

[.oisyn]

Matis schreef op dinsdag 03 mei 2011 @ 15:45:
[...]

Waarom geen preprocessor-blok er omheen?

Hoe gaat zo'n blok ervoor zorgen dat het altijd wordt uitgevoerd?

Wat je wel nog altijd kan doen is true|| of false&& voor de conditie zetten om 'm al dan niet uit te laten voeren.

[ Voor 20% gewijzigd door .oisyn op 03-05-2011 16:14 ]

[BasieP]

kenneth schreef op dinsdag 03 mei 2011 @ 15:49:
[...]
Eh Eerst zeg je dat je het niet moet veranderen omdat je de instellingen daarvoor aanpast, daarna reageer je op mijn post met de opmerking dat het geen instelling is?

nee nee nee...
we praten langs elkaar heen

Ik zeg dat visual studio van je { op zelfde regel een { op nieuwe regel maakt. Tenzij je de standaard instellingen daarvoor aanpast. (en dat is iets dat ik liever niet doe)

Jij zegt dat het gebruik van

C#:

if (condition) 
{
    doStuff();
}

boven het gebruik van

C#:

if (condition) 
    doStuff();

een standaard instelling is.

Waarop ik zegt dat dit niet zo is.

---

Anyway:
Wanneer je met je hele team van de 'standaard' afwijkt kan je inderdaad samenwerken. Maar je ziet steeds vaker dat kleine opensource projecten uit verschillende repositories onderdeel worden van je solutions.

Zodoende kan je binnen je solution 2 coding standaarden hebben. 1 van je eigen bedrijf, en 1 van het opensource projectje dat je in je solution hebt geinclude.
Omdat elk bedrijf wel z'n eigen standaarden kan bedenken die hun 'heel logisch' lijken, en toch afwijken van 'de standaard' is dit erg vervelend.

hoe graag ik ook normale tabs wil en geen spaties ben ik er toch voor om de standaard visual studio settings te blijven gebruiken. Gewoon omdat je dan met 'de wereld' kunt blijven praten.

.oisyn schreef op dinsdag 03 mei 2011 @ 16:13:
[...]

Hoe gaat zo'n blok ervoor zorgen dat het altijd wordt uitgevoerd?

zo:

C#:

#if !DEBUG
if (condition) 
{
#endif
    doStuff();
#if !DEBUG
}
#endif

[ Voor 9% gewijzigd door BasieP op 03-05-2011 17:14 ]

[kenneth]

BasieP schreef op dinsdag 03 mei 2011 @ 17:13:
Jij zegt dat het gebruik van

C#:

if (condition) 
{
    doStuff();
}

boven het gebruik van

C#:

if (condition) 
    doStuff();

een standaard instelling is.

Dat zeg ik helemaal niet, daar ga je al de fout in

[Verwijderd]

Hee pssst,..

BasieP schreef op dinsdag 03 mei 2011 @ 17:13:
* knip bla bla knip *

hoe graag ik ook normale tabs wil en geen spaties ben ik er toch voor om de standaard visual studio settings te blijven gebruiken. Gewoon omdat je dan met 'de wereld' kunt blijven praten.

Alex) schreef op dinsdag 03 mei 2011 @ 15:52:
Mijn voorkeur is om braces op een eigen regel te hebben, zodat ik snel kan zien welke braces bij elkaar horen. Werk ik in andermans code (in Visual Studio) waarbij de braces of indenting niet klopt, doe ik een snelle Ctrl+K Ctrl+D en klopt alles weer.

:W

[.oisyn]

BasieP schreef op dinsdag 03 mei 2011 @ 17:13:

C#:

#if !DEBUG
if (condition) 
{
#endif
    doStuff();
#if !DEBUG
}
#endif

Ja, idd een stuk makkelijker dan gewoon de if() uitcommenten
(het ging trouwens om { op dezelfde regel, waardoor de // niet werkt)

C#:

//if (condition)
{
    doStuff();
}

// of

if (true || condition) {
    doStuff();
}

hoe graag ik ook normale tabs wil en geen spaties ben ik er toch voor om de standaard visual studio settings te blijven gebruiken. Gewoon omdat je dan met 'de wereld' kunt blijven praten.

Dan ga je er voor het gemak maar vanuit dat de hele wereld gewoon de standaard instellingen gebruikt. Ik kan je alvast vertellen, ik doe daar iig lekker niet aan mee .

Ik dacht trouwens dat tabs standaard was in VS?

[ Voor 57% gewijzigd door .oisyn op 03-05-2011 18:44 ]

[kenneth]

Verwijderd schreef op dinsdag 03 mei 2011 @ 17:55:
Hee pssst,..


[...]


[...]


:W

Wat pssst?

[Verwijderd]

kenneth schreef op dinsdag 03 mei 2011 @ 18:42:
[...]

Wat pssst?

Was voor BassieP bedoeld... Hij blijft telkens maar zijn 'punt' aan halen dat het niet goed is om van de standaard instellingen af te wijken, omdat dat voor andere mensen niet werkt. Maar door een simpele sneltoets zet hij het om naar je eigen instellingen, dus non-issue.

[kenneth]

Geen non-issue als je een gezamenlijke repository gebruikt.

[Alex)]

.oisyn schreef op dinsdag 03 mei 2011 @ 18:40:
[...]
Ik dacht trouwens dat tabs standaard was in VS?

Nope, standaard VS is 4 spaties _{naar mijn weten}.

[.oisyn]

kenneth schreef op dinsdag 03 mei 2011 @ 18:47:
Geen non-issue als je een gezamenlijke repository gebruikt.

En daarom gebruik je tabs, zodat iedereen fijn zijn eigen instelling kan gebruiken

[kenneth]

Eigenlijk zou een VCS whitespace moeten negeren. Kan je zelf zo vaak op enter, spatie of tab rammen als je zelf wil ...

[BasieP]

kenneth schreef op dinsdag 03 mei 2011 @ 18:47:
Geen non-issue als je een gezamenlijke repository gebruikt.

tnx for making my point. Dat was idd waarom ik voor standaard settings ben. Niet zozeer voor mijzelf, maar voor de wereld. (ofzo)

Verder ben ik ook groot voorstander van tabs, en kan MS wel schieten voor default 4 spaties VS settings... Maargoed. Dan maar 4 spaties...

Alles voor standaarden

Eigenlijk zou een VCS whitespace moeten negeren. Kan je zelf zo vaak op enter, spatie of tab rammen als je zelf wil ...

eigenlijk zou in je project settings de coding standaarden als file bewaard moeten worden, zodat je al je settings in je repository staan, en iedereen die van die repo gebruik maakt dus automagisch dezelfde settings gebruikt.

[ Voor 27% gewijzigd door BasieP op 03-05-2011 19:44 ]

[Woy]

BasieP schreef op dinsdag 03 mei 2011 @ 19:42:
[...]
Verder ben ik ook groot voorstander van tabs, en kan MS wel schieten voor default 4 spaties VS settings... Maargoed. Dan maar 4 spaties...

Alles voor standaarden

Maar hoe moeilijk is het om gewoon voor iedereen in je team een .vssettings ( o.i.d. ) beschikbaar te maken waar de settings in staan die je hebt afgesproken. Als je niet in dezelfde editor werkt dan zullen de settings overigens ook al niet overeen komen, in het bedrijfsleven zul je dat niet veel tegenkomen, maar in de OS wereld bijvoorbeeld wel.

Het belangrijkste is dat je gewoon afspraken maakt die werkbaar zijn, en die ook gevolgd worden.

[BasieP]

Woy schreef op dinsdag 03 mei 2011 @ 19:50:
[...]

Maar hoe moeilijk is het om gewoon voor iedereen in je team een .vssettings ( o.i.d. ) beschikbaar te maken waar de settings in staan die je hebt afgesproken. Als je niet in dezelfde editor werkt dan zullen de settings overigens ook al niet overeen komen, in het bedrijfsleven zul je dat niet veel tegenkomen, maar in de OS wereld bijvoorbeeld wel.

Het belangrijkste is dat je gewoon afspraken maakt die werkbaar zijn, en die ook gevolgd worden.

true. Dit moet idd kunnen, maar wederom mijn argument dat je soms aan 2 projecten werkt die elk hun eigen coding standaard hebben. Doordat je settings per visual studio instantie zijn is dit irritant.

Je wilt settings per project en dan liefst zo dat ze in de repo van je project opgenomen kunnen worden en automagisch werken bij het openen van het project.

Zo houd je je niet alleen aan standaarden, maar dwing je ze ook af.

[RayNbow]

kenneth schreef op dinsdag 03 mei 2011 @ 19:10:
Eigenlijk zou een VCS whitespace moeten negeren. Kan je zelf zo vaak op enter, spatie of tab rammen als je zelf wil ...

Hoe moet een VCS weten welke whitespace hij moet negeren?

[kenneth]

RayNbow schreef op dinsdag 03 mei 2011 @ 20:25:
[...]

Hoe moet een VCS weten welke whitespace hij moet negeren?

Het is een mindfart hoor maar het zou toch moeten kunnen? Een compiler kan het ook. Mijn hello, world werkt precies hetzelfde als ik er veertig tabs en linefeeds doorheen jaag. Natuurlijk niet in string literals maargoed, dat lijkt mij geen raketwetenschap.

[BasieP]

kenneth schreef op dinsdag 03 mei 2011 @ 20:28:
[...]

Het is een mindfart hoor maar het zou toch moeten kunnen? Een compiler kan het ook. Mijn hello, world werkt precies hetzelfde als ik er veertig tabs en linefeeds doorheen jaag. Natuurlijk niet in string literals maargoed, dat lijkt mij geen raketwetenschap.

je wilt alleen net dat je editor gewoon je code opmaakt en dus juist je whitespaces formateerd.

ik heb vaak genoeg dat ik iets in een if statement heb staan, en dan later het if-statement weghaal.
dan moet alles dus 4 spaties naar links wat er tussen stond...

tja met een editor die whitespaces niet opmaakt wordt je code snel een chaos

[kenneth]

De editor moet dat natuurlijk gewoon doen, gebaseerd op je eigen instellingen. Maar voor versiebeheer zou dat niet moeten uitmaken omdat het nut (ik negeer Python even) voor de compiler 0,0 is.

Dan kan je lekker instellen dat je het inspringen op vijf spaties wil terwijl je collega dat op achttien spaties heeft staan zonder dat je last van elkaar hebt.

[Soultaker]

Ik zou sowieso een override willen om veranderingen in whitespace wél te kunnen committen, want als iemand inconsistent geïndenteerde code commit, dan moet dat wel te fixen zijn.

Verder lijkt het me vooral een client-side feature: als de client effectief een diff -b in plaats van diff op gewijzigde bestanden doet, dan ben je er al.

Met de huidige tools is het misschien praktischer om een hook te maken die je code layout volgens een bepaalde standaard (gofmt voor Go, GNU indent voor C, et cetera) zodat je altijd genormaliseerde files commit.

[ Voor 52% gewijzigd door Soultaker op 03-05-2011 20:50 ]

[kenneth]

Hmm, goed idee

Ik ga daar deze week eens even mee rotzooien.

[RayNbow]

kenneth schreef op dinsdag 03 mei 2011 @ 20:28:
[...]

Het is een mindfart hoor maar het zou toch moeten kunnen? Een compiler kan het ook. Mijn hello, world werkt precies hetzelfde als ik er veertig tabs en linefeeds doorheen jaag. Natuurlijk niet in string literals maargoed, dat lijkt mij geen raketwetenschap.

Het is geen rocket science, maar je moet de VCS wel informeren met wat hij te maken heeft. In sommige talen maakt whitespace wel uit. Zo mag je in het volgende voorbeeld het aantal spaties aan het begin van de 2e regel niet veranderen:
 

Haskell:

main = do putStr "Hello "
          putStrLn "World!"

[doskabouter]

Alex) schreef op dinsdag 03 mei 2011 @ 14:57:
Kwam zojuist dit tegen:

C#:

var sb = new StringBuilder();

int count = 0;
foreach (string s in Parameters)
{
    sb.Append(s);
    if (count < (Parameters.Count - 1))
    {
        sb.Append(", ");
    }
    else
    {
        sb.Append(" ");
    }
    count++;
}

Vervangen door:

C#:

var query = string.Join(", ", Parameters.ToArray()) + " ";

Veel mooier imo.

Die moet ik onthouden!

Vandaag een vergelijkbaar gedrocht zitten kloppen waar "OR" tussen moest, en uit luiheid (geen counter willen bijhouden) maar "true" achter de string geplakt...

[Dido]

doskabouter schreef op dinsdag 03 mei 2011 @ 21:19:
Vandaag een vergelijkbaar gedrocht zitten kloppen waar "OR" tussen moest, en uit luiheid (geen counter willen bijhouden) maar "true" achter de string geplakt...

code:

string Blaat = "true"

Was een stuk simpeler geweest

[ Voor 22% gewijzigd door Dido op 03-05-2011 21:41 ]

[doskabouter]

Dido schreef op dinsdag 03 mei 2011 @ 21:39:
[...]

code:

string Blaat = "true"

Was een stuk simpeler geweest

Inderdaad, na wat vreemde resultaten had ik er ipv "true", "false" achtergezet

[BasieP]

doskabouter schreef op dinsdag 03 mei 2011 @ 21:19:
[...]


Die moet ik onthouden!

Vandaag een vergelijkbaar gedrocht zitten kloppen waar "OR" tussen moest, en uit luiheid (geen counter willen bijhouden) maar "true" achter de string geplakt...

ik doe dan meestal zoiets:

C#:

StringBuilder sb = new StringBuilder();
foreach (String s in Stringlijst)
{
    sb.Append(s + ", ");
}
sb.Remove(sb.Length - 2, 2);

maar linq is idd veel mooier

[ Voor 3% gewijzigd door BasieP op 03-05-2011 21:59 ]

[.oisyn]

kenneth schreef op dinsdag 03 mei 2011 @ 20:28:
[...]

Het is een mindfart hoor maar het zou toch moeten kunnen? Een compiler kan het ook. Mijn hello, world werkt precies hetzelfde als ik er veertig tabs en linefeeds doorheen jaag. Natuurlijk niet in string literals maargoed, dat lijkt mij geen raketwetenschap.

In een ideale wereld zou ik sowieso afstappen van tekstbestanden. Het gaat feitelijk alleen om de tokenstream, je IDE zou die wel in een automatisch geformatteerde texteditor kunnen tonen. Verder zou je dan wat meer media als comments kunnen includen. Een grafiekje of een doodle oid. Code kan gewoon geordend worden op namespace en class, en wellicht ook handgedefinieerde views. Essentieel is wel dat dit ook begrepen wordt door sourcecontrol software.

Was dat niet ook een keer voorbij gekomen in de devschuur coffee corner, die aparte editor waarmee je gewoon op een groot wit canvas werkt en naar hartelust code fragments kon neerplempen om te editen?

[ Voor 3% gewijzigd door .oisyn op 03-05-2011 22:11 ]

[Sebazzz]

.oisyn schreef op dinsdag 03 mei 2011 @ 22:11:
[...]

Was dat niet ook een keer voorbij gekomen in de devschuur coffee corner, die aparte editor waarmee je gewoon op een groot wit canvas werkt en naar hartelust code fragments kon neerplempen om te editen?

Dat was een VS extensie afaik

[Matis]

Sebazzz schreef op dinsdag 03 mei 2011 @ 23:10:
Dat was een VS extensie afaik

Dat was ook het eerste wat mij te binnen schoot. Kan zo snel niet meer terugvinden; Misschien was het ook wel in het VS2010-topic.

[PrisonerOfPain]

.oisyn schreef op dinsdag 03 mei 2011 @ 22:11:
In een ideale wereld zou ik sowieso afstappen van tekstbestanden. Het gaat feitelijk alleen om de tokenstream, je IDE zou die wel in een automatisch geformatteerde texteditor kunnen tonen. Verder zou je dan wat meer media als comments kunnen includen. Een grafiekje of een doodle oid. Code kan gewoon geordend worden op namespace en class, en wellicht ook handgedefinieerde views. Essentieel is wel dat dit ook begrepen wordt door sourcecontrol software.

http://www.squeak.org + Monticello

Volgens mij ontbreken dan elleen de graphics nog in je comments maar kwa features komt 't redelijk overeen.

[eekhoorn12]

.oisyn schreef op dinsdag 03 mei 2011 @ 22:11:
[...]
Was dat niet ook een keer voorbij gekomen in de devschuur coffee corner, die aparte editor waarmee je gewoon op een groot wit canvas werkt en naar hartelust code fragments kon neerplempen om te editen?

Doet mij denken aan Code Bubbles http://www.cs.brown.edu/people/acb/codebubbles_site.htm

[Woy]

BasieP schreef op dinsdag 03 mei 2011 @ 21:58:
[...]
maar linq is idd veel mooier

Het code voorbeeld van Alex) heeft niet zo heel veel met Linq te maken, alleen de ToArray extension method komt uit de Linq namespace

C#:

var query = string.Join(", ", Parameters.ToArray()) + " ";

[Matis]

eekhoorn12 schreef op woensdag 04 mei 2011 @ 01:14:
Doet mij denken aan Code Bubbles http://www.cs.brown.edu/people/acb/codebubbles_site.htm

Jup, dat was idd de plugin die ik voor ogen had

[.oisyn]

eekhoorn12 schreef op woensdag 04 mei 2011 @ 01:14:
[...]


Doet mij denken aan Code Bubbles http://www.cs.brown.edu/people/acb/codebubbles_site.htm

Dat was wat ik bedoelde idd

[StM]

Ik heb me gelijk maar aangemeld voor de beta, jammer dat het nog alleen maar voor java is

[Verwijderd]

Kwam vandaag wat moois tegen:

PHP:

$_threeDays = date('Y-m-d', strtotime('+4 days'));

Wat een logica!

[BasieP]

Verwijderd schreef op donderdag 05 mei 2011 @ 17:43:
Kwam vandaag wat moois tegen:

PHP:

$_threeDays = date('Y-m-d', strtotime('+4 days'));

Wat een logica!

dat is gewoon een manier om te zorgen dat je niet heel snel ontslagen wordt.
Jij bent dan de enige die het snapt

ook wel JSTCO

[ Voor 14% gewijzigd door BasieP op 09-05-2011 13:22 ]

[Tsunami]

StM schreef op woensdag 04 mei 2011 @ 16:25:
Ik heb me gelijk maar aangemeld voor de beta, jammer dat het nog alleen maar voor java is

Uiteraard heeft Microsoft het weer gekopieerd voor VS2010 en Code Canvas genoemd, het is alleen nog niet te krijgen volgens mij, en aan het filmpje te zien werkt Code Bubbles nog steeds een stuk beter.

YouTube: Code Canvas in Visual Studio

[PrisonerOfPain]

Tsunami schreef op dinsdag 10 mei 2011 @ 11:08:
[...]

Uiteraard heeft Microsoft het weer gekopieerd voor VS2010 en Code Canvas genoemd.

Gekopieerd, ik denk dat die gast z'n Code Bubbles concept gewoon verkocht heeft.

https://twitter.com/#!/An.../status/64138108240793600

[.oisyn]

Ja maar het is natuurlijk veel stoerder om te zeggen dat MS weer eens wat gejat heeft.

[PrisonerOfPain]

Ik ben eigenlijk vooral benieuwd of dit ook voor unmanaged code uit komt aangezien die callstack visualizatie er wel erg tijdbesparend uit ziet.

[CodeCaster]

Echt, sommige mensen zou je een computerverbod voor de rest van hun leven geven. Kom ik nu weer een stuk code tegen waarin de huidige datum en tijd wordt opgeslagen in de database, en de tijd ook nog eens apart (in een varchar(5)...)! Het enige wat de code er omheen verder nog doet is die tijd in een textbox zetten.

Je zou toch eens FormatDateTime(sqldatetime, 'hh:nn') moeten intikken!

[Rutix]

BasieP schreef op maandag 09 mei 2011 @ 08:14:
[...]

dat is gewoon een manier om te zorgen dat je niet heel snel ontslagen wordt.
Jij bent dan de enige die het snapt

ook wel JSTCO

Template magic

is wel awesome

EDIT: 2x faail

[ Voor 20% gewijzigd door Rutix op 10-05-2011 13:53 ]

[Tsunami]

.oisyn schreef op dinsdag 10 mei 2011 @ 11:29:
Ja maar het is natuurlijk veel stoerder om te zeggen dat MS weer eens wat gejat heeft.

Moeten ze het maar niet zo makkelijk maken af en toe En soms bedenken ze ook wel goede dingen.

[pkuppens]

Ik weet niet of het in aanmerking komt, maar je kunt overdrijven met whitespace:

code:

    while (someCondition) 
    {





        if (
            (anotherCondition)

[Davio]

Room for comments?

[Matis]

Tsunami schreef op dinsdag 10 mei 2011 @ 15:03:
Moeten ze het maar niet zo makkelijk maken af en toe En soms bedenken ze ook wel goede dingen.

Heb je voorbeeldjes? Want voor zover ik me kan herinneren, heeft Microsoft na overnames het product niet laten versloffen, maar er veel tijd en moeite in genomen het uit te werken.

[.oisyn]

Davio schreef op dinsdag 10 mei 2011 @ 15:34:
Room for comments?

Precies, nadat je het hebt uitgeprint

[PrisonerOfPain]

.oisyn schreef op dinsdag 10 mei 2011 @ 15:53:
[...]

Precies, nadat je het hebt uitgeprint

Post-its of zoiets in de kantlijn (en dan achterop verder gaan bij een er op lijkend tekentje).

code:

'---`
| 1 |
`---'
   \
    \

't Feit dat ik hier een systeem voor heb betekend waarschijnlijk dat ik al veel te veel bomen verwoest heb

[Avalaxy]

---------------------------
Microsoft Visual Studio
---------------------------
Microsoft Visual Studio

TF31002: Unable to connect to this Team Foundation Server: [knip].

Team Foundation Server Url: [knip].


Possible reasons for failure include:

- The name, port number, or protocol for the Team Foundation Server is incorrect.

- The Team Foundation Server is offline.

- The password has expired or is incorrect.


Technical information (for administrator):

Unable to connect to the remote server
---------------------------
OK Help
---------------------------

Lekker informatief nog

[Alex)]

Het is niet in zoverre slecht of fout, maar de code in de .NET-wrapper voor de iRail API verdient geen schoonheidsprijs. Voorbeeldje: een bestand genaamd RailEngine.cs wat kennelijk het belangrijkste bestand is.

Een paar dingetjes die me opvallen:
- Een halfslachtige implementatie van het Singleton-pattern: ik zie een public static variabele genaamd Instance (die ook in o.a. de tests en sample code gebruikt wordt) maar de constructor is niet private. Waarom dan die "Instance"?
- Het gebruik van preprocessor directives (#if SILVERLIGHT) waardoor code die toch wel erg nuttig kan zijn (zoals het asynchroon inladen van de gegevens) alleen beschikbaar is voor Silverlight.
- Het gebrek aan ook maar enige vorm van documentatie of comments.
- Het overmatig gebruik van zulke try/catch-blokken:

C#:

public void EenOfAndereMethod()
{
    try
    {
        // bla
    }
    catch (Exception ex)
    {
       throw ex;
    }
}

Er wordt dus niets met eventuele fouten gedaan, én daarnaast wordt de stacktrace nog eens gesloopt waardoor debuggen nog wat lastiger wordt.

- Het gebrek aan gebruik van String.Format of StringBuilder:

C#:

private string FormatVehicleUrl(string vehicle)
{
    string url = string.Empty;
    url = GetVehicleUrl + "?";
    url += "id=" + vehicle;
    return url;
}

- En als kers op de taart: het niet gebruiken van de DateTime formatting parameters:

C#:

private string FormatDate(DateTime date)
{
    try
    {
        string formatedDate = string.Empty;
        string day = (date.Day > 9 ? date.Day.ToString() : "0" + date.Day.ToString());
        string month = (date.Month > 9 ? date.Month.ToString() : "0" + date.Month.ToString());
        string year = date.Year.ToString().Substring(2);
        formatedDate = day + month + year;
        return formatedDate;
    }
    catch (Exception ex)
    {
        throw ex;
    }
}

private string FormatTime(DateTime time)
{
    try
    {
        string formatedTime = string.Empty;
        string hour = (time.Hour > 9 ? time.Hour.ToString() : "0" + time.Hour.ToString());
        string min = (time.Minute > 9 ? time.Minute.ToString() : "0" + time.Minute.ToString());
        formatedTime = hour + min;
        return formatedTime;
    }
    catch (Exception ex)
    {
        throw ex;
    }
}

Oh, en ik kreeg de boel niet werkend op mijn machine. Ik kreeg een exception wanneer ik de actuele vertrektijden voor Antwerpen Centraal wilde opvragen, en dat was het dan. Toch jammer, want het idee is leuk.

[ Voor 5% gewijzigd door Alex) op 11-05-2011 09:05 ]

[Haan]

Alex) schreef op woensdag 11 mei 2011 @ 08:53:
Het is niet in zoverre slecht of fout
[..]

Ik bestempel deze voorbeelden toch als zowel slecht als fout hoor Met name die try/catch constructie is ronduit verwerpelijk.

[D-Raven]

Zat net nog even te kijken naar die RailEngine.cs. Maar sakkerju wat een monster zeg

[Alex)]

Haan schreef op woensdag 11 mei 2011 @ 08:59:
[...]

Ik bestempel deze voorbeelden toch als zowel slecht als fout hoor Met name die try/catch constructie is ronduit verwerpelijk.

Ik probeer nog vriendelijk te blijven voor degene die het heeft geschreven, misschien is het geen ervaren programmeur.

D-Raven schreef op woensdag 11 mei 2011 @ 09:01:
Zat net nog even te kijken naar die RailEngine.cs. Maar sakkerju wat een monster zeg

Mee eens, het ding doet veel te veel. Het is ook de enige class die volgens mij iets doet, de rest van de classes in dat project zijn alleen maar classes met wat properties en collections, voor zover ik kan zien.

[D-Raven]

SoC en SRP heeft deze persoon duidelijk nog niet helemaal in de vingers . Maargoed feit dat het Open Source is bied wel mogelijkheden voor wat constructieve feedback naar deze gast.

[ctrlaltdelbe]

Haan schreef op woensdag 11 mei 2011 @ 08:59:
[...]

Ik bestempel deze voorbeelden toch als zowel slecht als fout hoor Met name die try/catch constructie is ronduit verwerpelijk.

Dan snap je mijns insziens het nut van een try-catch methode echt niet. Maar heeft dit eigenlijk uberhaupt zin? Als je opnieuw een throw doet, moet je dan bij de declratie van de methode (ik denk in Java) niet alsnog 'throws SomeException' toevoegen, waardoor het catchen van de fout geen zin heeft?

[Alex)]

Vraagje: wat zouden jullie zoal doen om die code te verbeteren? Ik ben eigenlijk wel benieuwd wat jullie nu als "best practice" beschouwen.

[alienfruit]

ILeukeNaamParserFactory, LeukeNaamParserFactory, ILeukeNaamParser, LeukeNaamParser

code:

[Inject]
public var parserFactory: ILeukeNaamParserFactory;

var parser: ILeukeNaamParser = parserFactory.createDataParser();
var data: ICollection = parser.parseData( data );
return data;

[ Voor 6% gewijzigd door alienfruit op 11-05-2011 09:17 ]

[Alex)]

Nikolas schreef op woensdag 11 mei 2011 @ 09:11:
[...]

Dan snap je mijns insziens het nut van een try-catch methode echt niet. Maar heeft dit eigenlijk uberhaupt zin?

Ik ben van mening dat als je een fout afvangt, dat je er iets mee moet doen. Op z'n minst log je de error en rethrow je hem. In de situatie hier voegt de try/catch niets toe... sterker nog, het bemoeilijkt debuggen.

Als je opnieuw een throw doet, moet je dan bij de declratie van de methode (ik denk in Java) niet alsnog 'throws SomeException' toevoegen, waardoor het catchen van de fout geen zin heeft?

In C# is dat niet nodig. In principe kan alles een exception gooien (zelfs het setten van een property), daar moet je dus op bedacht zijn als je met libraries werkt van derde partijen.

[.Gertjan.]

Alex) schreef op woensdag 11 mei 2011 @ 09:28:
In C# is dat niet nodig. In principe kan alles een exception gooien (zelfs het setten van een property), daar moet je dus op bedacht zijn als je met libraries werkt van derde partijen.

Aan de ene kant is dat jammer, en aan de andere kant ook wel fijn. In Java kunt je wel forceren dat iemand bij het aanroepen van een functie foutafhandeling implementeert, maar het lijdt vaak ook tot een overvloed aan try/catch blokken.

In het begin heb ik het wel gemist, maar tja op andere vlakken is .Net sowieso superieur aan Java en wil ik niet meer terug.

C#:

hoenderhok.Insert(knuppel);

[martijnve]

Niet heel erg maar wel lekker overbodig lang(rechstreeks van msdn.microsoft.com)

C#:

// Create the NetworkStream for communicating with the remote host.
NetworkStream myNetworkStream;

if (networkStreamOwnsSocket){
     myNetworkStream = new NetworkStream(mySocket, true);          
}
else{
     myNetworkStream = new NetworkStream(mySocket);     
}

[.Gertjan.]

martijnve schreef op woensdag 11 mei 2011 @ 09:56:
Niet heel erg maar wel lekker overbodig lang(rechstreeks van msdn.microsoft.com)

C#:

// Create the NetworkStream for communicating with the remote host.
NetworkStream myNetworkStream;

if (networkStreamOwnsSocket){
     myNetworkStream = new NetworkStream(mySocket, true);          
}
else{
     myNetworkStream = new NetworkStream(mySocket);     
}

Och dit valt nog mee. Ik kwam afgelopen week if blokken tegen waar 10 regels in stonden waarbij slechts 1 regel afweek. De afwijking was nog zo minimaal dat het makkelijk met een

code:

myVal = expression ? "oplossing1" : "oplossing2";

af te handelen was, maar nee de fucktardontwikkelaar vond het beter om alles maar te copy pasten en in if blokken te wrappen. Paste goed bij de rest van de code, want ook functies bevatte behoorlijk wat overlap. Twee functies die een bestand moesten verplaatsen (van en naar een temp) bevatte beide de logica om IOPermission aan te vragen, te checken of de file bestond en het bestand daadwerkelijk te verplaatsen...

When does the hurting stop....

[Haan]

Nikolas schreef op woensdag 11 mei 2011 @ 09:11:
[...]

Dan snap je mijns insziens het nut van een try-catch methode echt niet. Maar heeft dit eigenlijk uberhaupt zin? Als je opnieuw een throw doet, moet je dan bij de declratie van de methode (ik denk in Java) niet alsnog 'throws SomeException' toevoegen, waardoor het catchen van de fout geen zin heeft?

Bedoel je nou dat IK het nut van try / catch blokken niet ken? Gelukkig bevestig je vanaf de tweede zin meteen dat je het eigenlijk zelf niet helemaal snapt

Wat is er fout aan het catchen van Exception en vervolgens deze exception meteen te throwen:
- in de eerste plaats vang je überhaupt alleen exceptions op waar je iets zinnigs mee kan. Hooguit heb je ergens een soort van 'catch all' die wel alles vangt, maar die zal er vervolgens ook iets zinnigs mee doen (zoals bijvoorbeeld een actie triggeren dat er een onverwacht probleem is opgetreden, of op z'n minst de melding loggen)
- Als je dezelfde exception rethrowt help je de stacktrace om zeep (zoals Alex) al aangaf, waardoor het lijkt alsof de fout in die method is opgetreden. De try/catch constructie is hier compleet nutteloos.
- Het minste dat je kan doen als je een exception vangt, is de exception loggen. Waarom zou je anders de moeite doen om een exception te vangen als je er toch niets mee doet?

[.Gertjan.]

Haan schreef op woensdag 11 mei 2011 @ 10:05:
[...]


- Als je dezelfde exception rethrowt help je de stacktrace om zeep (zoals Alex) al aangaf, waardoor het lijkt alsof de fout in die method is opgetreden. De try/catch constructie is hier compleet nutteloos.

Behalve toch als je

C#:

try {
    int x = 5 / 0;
} catch (Exception e) {
   throw;
}

gebruikt? Dat is tenminste wat ik begrepen had toen ik me er verder in verdiept had. In het boek CLR via C# wordt dit ook genoemd.

[Haan]

.Gertjan. schreef op woensdag 11 mei 2011 @ 10:08:
[...]

Behalve toch als je

C#:

try {
    int x = 5 / 0;
} catch (Exception e) {
   throw;
}

gebruikt? Dat is tenminste wat ik begrepen had toen ik me er verder in verdiept had. In het boek CLR via C# wordt dit ook genoemd.

Klopt, maar dat is iets anders dan 'throw e' (en nog steeds nutteloos als dat het enige is dat je in het catch blok doet )

[ Voor 9% gewijzigd door Haan op 11-05-2011 10:10 ]

[.Gertjan.]

Haan schreef op woensdag 11 mei 2011 @ 10:10:
[...]

Klopt, maar dat is iets anders dan 'throw e' (en nog steeds nutteloos als dat het enige is dat je in het catch blok doet )

daar kwam ik dus ook achter
Maar wilde het even checken, en natuurlijk net doen of ik veel weet

[Verwijderd]

pkuppens schreef op dinsdag 10 mei 2011 @ 15:09:
Ik weet niet of het in aanmerking komt, maar je kunt overdrijven met whitespace:

code:

    while (someCondition) 
    {





        if (
            (anotherCondition)

Wij hadden een collega die dan in het commentaar functioneel beschreef wat er moest gebeuren en dat dit wel moeilijk te programmeren was. En omdat dit moeilijk was ook hoe je dit handmatig moest fixen mocht het nodig zijn ....

[alienfruit]

Ach, ik heb hier code dat ik vorig jaar geschreven heb en snap er de ballen van. Natuurlijk zonder bruikbaar commentaar.

[MBV]

Dat is altijd zo leuk. * MBV roept hardop: Welke fucktard heeft die code nou weer geschreven? even opzoeken in het versiebeheersysteem. Oh ja, nu weet ik het weer

[Zsub]

Klein stukje Objective C:

C:

if (days == 1){
        bier1.image = [UIImage imageNamed:@"1.png"];
    }
    if (days == 2){
        bier1.image = [UIImage imageNamed:@"2.png"];
    }
    if (days == 3){
        bier1.image = [UIImage imageNamed:@"3.png"];
    }
    if (days == 4){
        bier1.image = [UIImage imageNamed:@"4.png"];
    }
    if (days == 5){
        bier1.image = [UIImage imageNamed:@"5.png"];
    }
    if (days == 6){
        bier1.image = [UIImage imageNamed:@"6.png"];
    }
    if (days == 7){
        bier1.image = [UIImage imageNamed:@"7.png"];
    }
    if (days == 8){
        bier1.image = [UIImage imageNamed:@"8.png"];
    }
    if (days == 9){
        bier1.image = [UIImage imageNamed:@"9.png"];
    }
    if (days == 10){
        bier1.image = [UIImage imageNamed:@"10.png"];
    }
    if (days == 11){
        bier1.image = [UIImage imageNamed:@"11.png"];
    }
    if (days == 12){
        bier1.image = [UIImage imageNamed:@"12.png"];
    }
    if (days == 13){
        bier1.image = [UIImage imageNamed:@"13.png"];
    }
    if (days == 14){
        bier1.image = [UIImage imageNamed:@"14.png"];
    }
    if (days == 15){
        bier1.image = [UIImage imageNamed:@"15.png"];
    }
    if (days == 16){
        bier1.image = [UIImage imageNamed:@"16.png"];
    }
    if (days == 17){
        bier1.image = [UIImage imageNamed:@"17.png"];
    }
    if (days == 18){
        bier1.image = [UIImage imageNamed:@"18.png"];
    }
    if (days == 19){
        bier1.image = [UIImage imageNamed:@"19.png"];
    }
    if (days == 20){
        bier1.image = [UIImage imageNamed:@"20.png"];
    }
    if (days == 21){
        bier1.image = [UIImage imageNamed:@"21.png"];
    }
    if (days == 22){
        bier1.image = [UIImage imageNamed:@"22.png"];
    }
    if (days == 23){
        bier1.image = [UIImage imageNamed:@"23.png"];
    }
    if (days == 24){
        bier1.image = [UIImage imageNamed:@"24.png"];
    }
    if (days == 25){
        bier1.image = [UIImage imageNamed:@"25.png"];
    }
    if (days == 26){
        bier1.image = [UIImage imageNamed:@"26.png"];
    }
    if (days == 27){
        bier1.image = [UIImage imageNamed:@"27.png"];
    }
    if (days == 28){
        bier1.image = [UIImage imageNamed:@"28.png"];
    }
    if (days > 28){
        bier1.image = [UIImage imageNamed:@"28.png"];
    }

Oplossing:

C:

bier1.image = [UIImage imageNamed:[NSString stringWithFormat:@"%i.png",days]];

[BM]

Dat is niet helemaal hetzelfde? Voor dagen >28 word in je 1e voorbeeld 28.png gebruikt, in je 2e voorbeeld probeerd ie er een 29/30/31.png van te maken, toch?

[Matis]

Volgens mij heb je gelijk.
Maar een eenvoudige wrapperfunctie met een getter, zou het al op moeten lossen.
Daarnaast weet ik niet of het op deze manier misschien beter optimaliseert.
Ik kan me niet voorstellen dat een ontwikkelaar deze code met het handje geklopt heeft zonder goede reden