Дмитрий

Есть книга "Совершенный код". Прочитайте ее разок. Попрограммируйте. Прочитайте через год еще раз. Многое встанет на свои места. После второго прочтения МакКонела прочитайте про "Чистый код" и затем читайте про рефакторинг. После этих трех книг Вы будете нас учить как писать код, а не мы Вас!

Рекомендую поступать так:
1. Если код нуждается в комментариях, то напишите по-английски, а затем создайте новый метод с использованием этого комментария и перенесите туда этот кусок кода. Возьмем к примеру Ваши "удаляет все записи" на код "clear : function(){" . Как бы вы написали по-английски? Наверное так "clear all records' , а почему бы текущего названия метода clear() не использовать комментарий clearAllRecords() ?
2. Задавайтесь вопросом: "Если это не открытый метод и я хочу закомментировать его, то может быть мне стоит его переписать?". Открытые методы это интерфейс, которым будут пользоваться другие программеры. Он ОБЯЗАН быть задокументирован. А внутренний код либо покрывается модульным тестом, который поясняет для чего нужен кусок кода и какой должен давать результат и дает ли? Другими словами ваш модульный тест это САМЫЙ лучший вид документации
3. Пишите всегда комментарий об алгоритмах, стандартах, положениях, хитрых трюках. К примеру "Этот алгоритм взят из книги Кнута том 2 стр. ЧЧЧЧ", тогда ваш коллега в случае сомнений пойдет и почитает как работает этот код в теории и поймет как должен работать и сравнит с тем что есть
4. Если же модульного теста нет, значит поленились и это вполне возможно тема для рефакторинга. На простой код, просто написать тест! То есть простой код - читать просто и тестировать просто!

Знать оба способа положено!

Способ "Сначала объявление, а потом где-нибудь определение" позволяет:

* Создавать так называемые "хидера" или файлы-заголовки, в которых пишутся как раз таки только и только объявления функций.
* Писать код не задумываясь о том, где именно будет определно тело функции. Главное чтобы оно было в одной и той же единице трансляции или доступна ссылка из другой.

Начинающим рекомендуют как раз-таки именно такой способ. А спустя время, когда у них развивается чувство кода, прекрассного, т.е. навыка писать достаточно структурированный и ясный код, то они сами того не замечая переходят на второй способ "Только тело без каких-либо предварительных объявлений" там где это возможно.

Я бы предпочел второй способ. Указывание типа ответа вполне логично. Явное лучше чем неявное.
Еще Вы можете без параметров, а прямо в endpoint-е от URI:

На псевдо-питоне:

@app.route('employes/<uiid:string>/format/<type:string>')
def get_empoyes(uuid, type):
   if type == 'json':
     pass
   elif type== 'xml':
     pass
   elif type == binary:
     pass
   else:
     abort(404)

Также отмечу, что ответ лучше всегда сопровождать с content-type. А то некоторые забывают и приходится писать детекторы формата ;(((

P.S.:
По выбору имен. Имя 'type' ни о чем не говорит. Тип чего? Ответа? А может тип служащего? Тип автомобиля на котором ездит служащий?

P.S. #2:
Рекомендую почитать статью-перевод на хабре "RESTful API для сервера – делаем правильно" и книгу, которую привели в конце части 2

1. Способ это переменная создаваяемая на стеке.
2. Это переменная создаваемая в динамической памяти. Если конечно Вы или "Ваш друг" с оператором new ничего не сделали.

Динамическая память куда большего размера чем область стека

Сначала о самых главных навыках ЛЮБОГО программиста:

1. Непрерывно улучшать чтение\письмо по-английски!
2. Уметь искать ответы в google.com или др. поисковую технологию
3. Всегда, всегда задаваться вопросом: "А может кто-то уже решил мою проблему?" и пользоваться навыком из п.2.

По сути вопроса:
1. Если опыта программирования нет, то я бы рекомендовал прочитать "C++ за 21 день" от Дж. Либерти
2. Если опыт есть, то читать книгу Лафоре про Объектно ориентированное программирование на C++
3. На этой стадии опыт написания кода уже есть, поэтому Стив Макконел с его Совершенным кодом
4. После этого читаются правила от Скотта Майерса, но через призму скептицизма. На этом этапе уже должен быть достаточно опыта чтобы понять что вам подходит, а что нет
5. Чтение Рефакторинга от Фаулера
6. Только на этоп этапе читать Страуструпа. Читать вдумчиво. Читать так, чтобы каждое его слово и каждая его мысль была понята, прочувтвована

Практикуясь той или иной фиче языка, идиоме рекомендую на реализациях алгоритмов сортировок, структур данных и всем что связано с алгоритмами.

Да, и читать надо по-умному! Для программиста чтение проф.литературы означает "Непрерывно вбивать код" и пытаться применить хотя бы в каком-нибудь 'hello world'-е изучаемой технологии или языке или идиоме. Только постоянная долбежка позволяет вбить в память пальцев нужные и правильные вещи на уровне инстинктов, которые экономят время при создании больших программных проектов.

UPD:
Один из нюансов чтения проф.литературы заключается в том, что почти никогда нет возможности прочитать с первого раза! Будьте терпеливы, т.к. наверняка Вам придется перечитывать как минимум абзац, не редкостью будет перечитывание 2-3 страниц, а иногда и целой главы с начала. Процесс проф.литературы - итеративный. С первого раза формируется "общее" представление с "дырыми" по прочитанному материалу. Повторное чтение закрывает часть этих "дыр". А паралельная практика при этом дает еще ясное понимание того как надо и как не надо и где именно у Вас не получается.