Hvor ofte bruker du pseudokode i den virkelige verden?

Jeg bruker pseudokode når du er borte fra en datamaskin og bare ha papir og penn. Det gjør ikke mye fornuftig å bekymre syntaks for kode som ikke vil kompilere (kan ikke kompilere papir).

Stort sett bruker det for Nutting ut veldig kompleks kode, eller når forklare koden til enten andre utviklere eller ikke utviklere som forstår systemet.

Jeg også flyte diagrammer eller UML typen diagrammer når du prøver å gjøre ovenfor også ...

Jeg bruker vanligvis det når utvikle multippel hvis annet uttalelser som er nestet som kan være forvirrende.

Denne måten jeg ikke trenger å gå tilbake og dokumentere det siden den allerede er gjort.

Ganske sjelden, selv om jeg ofte dokumentere en metode før du skriver kroppen av det.

Men hvis jeg hjelper en annen utvikler med hvordan å nærme seg et problem, vil jeg ofte skrive en e-post med en pseudokode løsning.

Jeg nesten alltid bruke det i dag når du oppretter alle ikke-trivielle rutiner. Jeg lage pseudokode som kommentarer, og fortsette å utvide det før jeg kommer til det punktet at jeg kan bare skrive det samme koden under det. Jeg har funnet dette betydelig raskere utvikling, reduserer "bare skrive kode" syndrom som ofte krever omskrivninger for ting som ikke var opprinnelig betraktet som det tvinger deg til å tenke gjennom hele prosessen før du skriver selve koden, og fungerer som god base for kode dokumentasjon etter at den er skrevet.

Jeg bruker ikke pseudokode i det hele tatt. Jeg er mer komfortabel med syntaksen til C-stil språk enn jeg er med pseudokode.

Hva jeg gjør ganske ofte for design formål er egentlig en funksjonell nedbrytning stil av koding.

public void doBigJob( params )
{
    doTask1( params);
    doTask2( params);
    doTask3( params);
}
private void doTask1( params)
{
    doSubTask1_1(params);
    ...
}

Som i en ideell verden ville til slutt slå ut i arbeids kode som metoder blir mer og mer trivielle. Men i det virkelige liv, det er en pokker for mye refactoring og tenke nytt design.

Vi finner dette fungerer godt nok, så sjelden vi kommer over en algoritme som er både: Utrolig kompleks og vanskelig å kode og ikke bedre løses ved hjelp av UML eller annen modelleringsteknikk.

Hvis jeg jobber ut noe komplisert, jeg bruker det mye, men jeg bruker det som kommentarer. For eksempel, vil jeg kategorisert ut prosedyren, og satt i hvert trinn jeg tror jeg trenger å gjøre. Som jeg da skrive koden, vil jeg la kommentarene: det står hva jeg prøver å gjøre.

procedure GetTextFromValidIndex (input int indexValue, output string textValue)
// initialize
// check to see if indexValue is within the acceptable range
//    get min, max from db
//    if indexValuenot between min and max
//       then return with an error
// find corresponding text in db based on indexValue
// return textValue
   return "Not Written";
end procedure;

Jeg har aldri, ikke en eneste gang, for å skrive pseudokode av et program før du skriver det.

Men det hender jeg har måttet skrive pseudokode etter å skrive kode, noe som vanligvis skjer når jeg prøver å beskrive høyt nivå implementering av et program for å få noen opp til hastighet med ny kode i løpet av kort tid. Og ved "high-level implementering", mener jeg en linje av pseudo beskriver 50 eller så linjer med C #, for eksempel:

Core-dumper en haug med XML-filer i en mappe og driver process.exe
  kjørbar med et par command parametere.

Den process.exe leser hver fil
    Hver fil blir lest linje for linje
    Unike ord er trukket ut av filen er lagret i en database
    Fil slettes når det er ferdig behandling