Как часто вы используете псевдокод в реальном мире?

Я использую псевдокод, когда вдали от компьютера и только бумага и ручка. Это не имеет особого смысла беспокоиться о синтаксисе для кода, который не компилируется (не может составить бумагу).

Главным образом использовать его для Nutting из очень сложного кода, или при объяснении кода либо других разработчиков или атеистических разработчикам, которые понимают систему.

Я также течь диаграммы или диаграммы типа UML при попытке сделать выше, также ...

Я вообще использовать его при разработке мультипликатор, если другого заявления, которые вложены, которые могут вызвать путаницу.

Таким образом, мне не нужно, чтобы вернуться и документировать его, так как его уже было сделано.

Довольно редко, хотя я часто описываю метод, прежде чем писать тело его.

Однако, если я помогаю другому разработчику, как подойти к проблеме, я часто пишу письмо с раствором псевдокода.

Я почти всегда использую его в настоящее время при создании каких-либо нетривиальные процедуры. Я создаю псевдокод как комментарии, и продолжать расширять его, пока я не до такой степени, что я могу просто написать эквивалентный код ниже него. Я обнаружил, что значительно ускоряет развитие, снижает синдром «просто писать код», который часто требует переделок для вещей, которые изначально не были рассмотрены, как это заставляет вас думать через весь процесс, прежде чем писать фактический код, и служит хорошей основой для код документации после него написано.

Я не использую псевдокод вообще. Я более комфортно с синтаксисом языков типа C, чем я с псевдокодом.

То, что я делать довольно часто для целей проектирования, по существу, функциональный стиль разложения кодирования.

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

Который, в идеальном мире, в конечном счете превратится в рабочий код, как методы становятся все более и более тривиальным. Однако в реальной жизни, есть чертовски много рефакторинга и переосмысление дизайна.

Мы считаем, что это работает достаточно хорошо, так как редко мы сталкиваемся с алгоритмом, который является одновременно: невероятно сложным и трудно кодировать и не лучше решить с помощью UML или иной метод моделирования.

Если я работаю вне что-то сложное, я использую его много, но я использую его в качестве комментариев. Например, я гашу процедуру, и поставить на каждом этапе, я думаю, что мне нужно сделать. Как я тогда писать код, я оставлю комментарии: он говорит, что я пытался сделать.

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;

Я никогда даже не один раз, нужно написать псевдокод программы перед записью.

Тем не менее, время от времени я должен был написать псевдокод после написания кода, который обычно происходит , когда я пытаюсь описать реализацию высокого уровня программы , чтобы заставить кого - то до скорости с новым кодом в коротком промежутке времени. И «осуществление на высоком уровне», я имею в виду одна линия псевдокод описывает 50 или около линии C #, например:

Дампы кучу файлов XML в папку и запускает process.exe
  исполняемый файл с несколькими параметрами командной строки.

Process.exe читает каждый файл
    Каждый файл построчно чтение
    Уникальные слова вырываются из файла, хранящегося в базе данных
    Файл будет удален, если его завершения обработки