TheHorse

Пусть игрушки программируют. Притом все разные. Это повышает вероятность того, что у них не пропадет интерес к программированию. К тому-же и математику подтянут, когда захотят что-то поинтересней сделать.

habrahabr.ru/qa/2380/ — вероятно тут вы найдете ответ.

Теория создания программного продукта (ТСПП), восславим декомпозицию. <теория хаоса> (ТХ) — не она конкретно, но все то, что защищает читателе кода от роста информационной энтропии головного мозга.

До тех пор, пока не выкинули из науки и GameDev-а:
Алгоритмы, высшая математика, дискретная математика, компьютерная лингвистика, кинематика, оптика, <еще куча математик>.

А теперь пытаюсь делать сайты — вот ничего (кроме ТСПП и ТХ) не использую.

1) В паскале нет GC и встроенных умных ссылок, и отсутствие ссылок ничего не изменяет.
2) Да.
3) Нет, в С мусор не собирается автоматически.

Еще недавно, там где я работаю, это зависело от языка и даже фреймворка (в случае наличия). Позавчера мне просто надоело видеть 2 разных варианта в пределах одного экрана, и теперь у нас везде применяется вариант с переносом.

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

P. S. За вариант без переноса в pascal-подобных языках просто убивать хочется:

var i : integer;
function rock(hard: boolean); begin
   for i := 1 to 10 do begin
       //do something
   end;
end;

Можно пробовать хеш функцию, которая является суммой всех символов div С, где С — константа, большая (например,100). Тогда с высокой долей вероятности, строки, которые отличаются на 1-2 символа будут попадать в один хеш.

В общем случае, для адресов не спасает расстояние Левенштейна, и не спасают какие либо хеш — функции.

Нарушением уровня абстракций, насколько я понимаю то, что вы вкладываете в понятие уровня абстракции, будет факт несогласованности интерфейса класса. Если у вас есть методы из названий которых следует, что они относятся к разным уровням абстракции, вы нарушили абстракцию класса. Другими словами, если в одном классе есть методы getCount и getCountOfFlat — на лицо нарушение абстрагирования. Появление таких методов вероятно при наличии наследования, которое я считаю исключением из правил.

На сколько я понимаю, из курса ТСПП, уровень абстракции — абстрактная величина, и не может быть вычислена.

Абстракция определяется исключительно интерфейсом класса, и не может быть нарушена за пределами этого класса.

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

P. S. Никогда не встречал понятие уровня абстракции за пределам контекста декомпозиции, может не правильно понял, следовательно, не правильно ответил :(

Нет, не могли бы. Не ссылочки вам нужны, а книги. Предпочтения по языкам/направлениям есть?
Фундаментальные алгоритмы — Т. Кормен «Алгоритмы. Построение и анализ.»

Для двоичного поиска нужно, чтобы R(k) была линейной, а вашем случае, если я не ошибаюсь, может быть что попало.

Полностью поддерживаю SLY_G.

Книги — источник систематически изложенной информации. Прочитайте хоть одну книгу по Pascal / C# (ну или что там еще простого есть (только не С, там сразу уклон в системное и сложновато будет, каким бы простым он не был)). А потом делайте что хотите:
1. Свой небольшой / большой проект, который научит думать и решать проблемы.
2. Чужой (open source) проект, где заставят делать правильно.
3. Юниором куда-то, где вас будут явно учить.

Ну и конечно, университет — очень полезен для программирования, даже если там программированию будет учить кто-то, кто сам ничего не понимает. Без фундамента, инженером (хорошим программистом) никто и никогда не станет. То бишь, быть может у вас получится решать поставленные задачи, но вы будете на это тратить намного больше времени, и решения будут менее эффективны.

Доп. инфа:
1. Учите математики, если вы не знаете что такое детерминант, ряды Тейлора, конъюнкция… — стыдно быть даже юниором.
2. Англ. — печально, но все самое интересное на англ. языке
3. Задавайте больше вопросов, но перед тем как их задавать пробуйте разбираться и думать самостоятельно.

Удачи вам.
P. S. Товарищи, не давайте вредных советов).

Основной источник — опыт).
Из книг — «Совершенный код».
Ну и конечно очень сильно помогает чтение хорошего кода.

Блок схемы — для алгоритмов, для архитектуры ПО — принципиальные схемы, UML…

Я думаю что следует начинать с «Язык программирования Си \\ Д. Ритчи». Вы просто рискуете не понять контекста компьютерной архитектуры, не попытавшись хоть что-то сделать практического. Читал книгу, понравилась. Вы главное ее не только читайте, но и делай-те упражнения из нее.

> Пробовал читать книги, смотреть видеоуроки, писать сложные и не очень программы, учить алгоритмы,
Всё правильно, так держать). И, главное, пытайтесь интересоваться тем, как оно работает на низком уровне.

Навыки программирования очень сложно оценить. Знание языка, вообще, почти не коррелируют с уровнем программиста. Знание паттернов — тоже. Частота использования гугла — тоже. Я, например, будучи программистом 10 лет, все еще по каждой мелочи пользуюсь гуглом, и так будет всегда.

Хорошего программиста определяет умение качественно решать, различного рода, задачи. Чем лучше программист, тем шире список решаемых им задач, и тем лучше качество решений, но и это все не объективно.

Единственное, что могу посоветовать — поискать ответы на вопросы такого рода.