ПРОЧЕЕ

macOS/iOS программирование
Аватара пользователя
admin
Администратор
Сообщения: 1103
Зарегистрирован: 18 янв 2012, 01:25
Откуда: Екатеринбург
Контактная информация:

ПРОЧЕЕ

Сообщение admin » 14 май 2021, 13:42


Аватара пользователя
admin
Администратор
Сообщения: 1103
Зарегистрирован: 18 янв 2012, 01:25
Откуда: Екатеринбург
Контактная информация:

Re: ПРОЧЕЕ

Сообщение admin » 14 май 2021, 14:04


Аватара пользователя
admin
Администратор
Сообщения: 1103
Зарегистрирован: 18 янв 2012, 01:25
Откуда: Екатеринбург
Контактная информация:

Re: ПРОЧЕЕ

Сообщение admin » 14 май 2021, 14:06


Аватара пользователя
admin
Администратор
Сообщения: 1103
Зарегистрирован: 18 янв 2012, 01:25
Откуда: Екатеринбург
Контактная информация:

Re: ПРОЧЕЕ

Сообщение admin » 14 май 2021, 14:10




Аватара пользователя
admin
Администратор
Сообщения: 1103
Зарегистрирован: 18 янв 2012, 01:25
Откуда: Екатеринбург
Контактная информация:

Re: ПРОЧЕЕ

Сообщение admin » 14 май 2021, 14:23



Аватара пользователя
admin
Администратор
Сообщения: 1103
Зарегистрирован: 18 янв 2012, 01:25
Откуда: Екатеринбург
Контактная информация:

Re: ПРОЧЕЕ

Сообщение admin » 14 май 2021, 14:40

Роберт Мартин: Чистый код. Создание анализ и рефакторинг
С.Макконнелл: Совершенный код практическое руководство по разработке програмного обеспечения

Аватара пользователя
admin
Администратор
Сообщения: 1103
Зарегистрирован: 18 янв 2012, 01:25
Откуда: Екатеринбург
Контактная информация:

Re: ПРОЧЕЕ

Сообщение admin » 14 май 2021, 14:46

взято тут

Имя должно отражать семантику, а не тип переменной. Имена вида s, list, array не дают полезной информации читателю.
Не используйте местоимения в именах. Это совсем не добавляет понятности.
Имя переменной должно отражать семантику. Старайтесь избегать однобуквенных имен. Общее правило: чем больше область видимости — тем подробнее должно быть имя.
В именах стоит отражать существенные особенности. Например, если переменная типа DateTime хранит только дату, можно назвать ее date.
Иногда, арифметические выражения понятнее, чем значение этого выражения. Запись 24 * 60 * 60 проще проверить на корректность, чем 86400.
Избегайте труднопроизносимых имен и кодирования, понятного лишь вам.
Не называйте булевы переменные flag, f и подобными именами. У каждого "флага" есть смысл, который и нужно отразить в имени.
В C# имена локальных переменных принято начинать с маленькой буквы. Нарушение таких, казалось бы, несущественных правил часто сильно раздражает опытных программистов.
В C# для составных имен принято использовать стиль CamelCase, и не использовать snake_case.
Не используйте русские слова в именах (если только вы не программируете на 1C). Читая код, программисты ожидают видеть английские имена, поэтому написанные транслитом
русские слова могут быть восприняты неправильно. Например, в данном случае col (количество) легко спутать с сокращением от слова column.
Отражайте в имени то, что важно при дальнейшем использовании. В данном случае то, что это имя входного файла важнее того, что оно получено из аргументов командной строки.
Handle — слово заместитель, не добавляющее смысла. В чем именно заключается "обработка"? Отразите это в имени вместо слова Handle.
Manager — слово заместитель, не добавляющее смысла. Часто его можно заменить на что-то более осмысленное. Например, менеджер по продажам может стать продавцом консультантом
Имена с номерами на конце — это антипаттерн. Вместо добавления номеров старайтесь отразить в именах суть различия.
Функцию с непонятными именами аргументов неудобно использовать.
Нет смысла писать комментарии, повторяющие код.
Нарушение правильного для английского языка порядка слов в составных именах — частая ошибка программистов со слабым знанием английского.
directoryInput с английского — это ввод директории. Входная директория — это inputDirectory.
Качество рендера — это QualityOfRender или просто RenderQuality.
ColorCell — это цветная клетка, а цвет клетки — CellColor. Не путайте — не вводите в замешательство читающих.
Для обозначения координат вместо i, j и a, b лучше использовать предсказуемые и понятные x, y.
Избегайте необходимости мысленного декодирования при чтении кода.
Не используйте закодированные или труднопроизносимые имена. Вам их придется произносить или хотя бы мысленно проговаривать!
Имя должно отражать семантику, а не тип переменной. Имена вида s, list, array не дают полезной информации читателю.
Переменные и классы — это сущности, а методы — действия. Имейте это в виду!
Методы GetXXX, CreateXXX, ReadXXX должны возвращать результат. void-методы, инициализирующие поля класса лучше так не называть.
Методы Set должны принимать устанавливаемое значение в качестве аргумента. Методы без аргументов лучше так не называть.
Вместо комментария, разделяющего код на две фазы, стоит сделать настоящее разделение кода на методы. Каждый метод должен делать ровно одну вещь.
Если вы можете естественным образом разбить один метод на два — сделайте это!
Вместо поясняющего комментария лучше изменить код так, чтобы в комментарии не было нужды.
Комментарии повторяющие код не нужны. Они легко могут устареть!
Сложные булевы выражения стоит выделять в методы или вспомогательные переменные, давая им говорящие названия. Это улучшит читаемость.
Cложные булевы выражения стоит выделять в методы или вспомогательные переменные, давая им говорящие названия. Это улучшит читаемость.
if (employee.DeservesFullBenefits()))
Комментарии вида 'конец цикла', 'конец функции' и подобные бессмысленны.
Для коротких функций такие комментарии не нужны, а длинные функции лучше разбить на несколько более коротких.
Современные среды разработки и программистские редакторы умеют подсвечивать парные скобки. Это надежнее таких комментариев.
Если появляется желание написать поясняющий комментарий к методу, стоит вместо этого постараться придумать более удачное имя методу.
Хорошие комментарии должны объяснять намерения программиста в тех случаях, когда их сложно выразить непосредственно кодом.
Комментарии вида 'конец цикла', 'конец функции' и подобные бессмысленны. Для коротких функций они не нужны, а длинные функции лучше
разбить на несколько более коротких, вместо написания таких комментариев.
Когда-то очень давно был смысл писать комментарии с историей изменения файла. Но сейчас вместо таких комментариев лучше использовать систему контроля версий и писать понятные сообщения к коммитам.
Не пишите XML-комментарий только для того, чтобы он был. В наличии комментария должен быть какой-то смысл.
XML-комментарии не несущие новой информации бесполезны.
XML-комментарии бессмысленны, если не несут новую информацию.
Не используйте комментарии там, где можно выделить метод с говорящим именем.
При виде комментария, разделяющего метод на смысловые части, стоит вынести эти смысловые части в отдельные методы.
Разделительные комментарии вроде такого часто показывают, что программист поленился выделить вспомогательный метод.
При виде комментария, разделяющего метод на смысловые части, стоит вынести эти смысловые части в отдельные методы.
Разделительные комментарии вроде такого часто показывают, что программист поленился выделить вспомогательный метод.
Логику инициализации полей карты лучше переместить в конструктор класса карты.
Устраняйте дублирование. Это делает код понятнее и надежнее.
В C# локальные переменные принято называть с маленькой буквы.

Аватара пользователя
admin
Администратор
Сообщения: 1103
Зарегистрирован: 18 янв 2012, 01:25
Откуда: Екатеринбург
Контактная информация:

Re: ПРОЧЕЕ

Сообщение admin » 14 май 2021, 15:01

Стивен С. Скиена Алгоритмы Руководство по разработке.

Аватара пользователя
admin
Администратор
Сообщения: 1103
Зарегистрирован: 18 янв 2012, 01:25
Откуда: Екатеринбург
Контактная информация:

Re: ПРОЧЕЕ

Сообщение admin » 14 май 2021, 16:25


Аватара пользователя
admin
Администратор
Сообщения: 1103
Зарегистрирован: 18 янв 2012, 01:25
Откуда: Екатеринбург
Контактная информация:

Re: ПРОЧЕЕ

Сообщение admin » 27 май 2021, 06:46


Аватара пользователя
admin
Администратор
Сообщения: 1103
Зарегистрирован: 18 янв 2012, 01:25
Откуда: Екатеринбург
Контактная информация:

Re: ПРОЧЕЕ

Сообщение admin » 27 май 2021, 08:24

классы UiKit
Вложения
uikit_classes.jpg
uikit_classes.jpg (162.17 КБ) 7553 просмотра


Аватара пользователя
admin
Администратор
Сообщения: 1103
Зарегистрирован: 18 янв 2012, 01:25
Откуда: Екатеринбург
Контактная информация:

Re: ПРОЧЕЕ

Сообщение admin » 04 июн 2021, 01:59


Аватара пользователя
admin
Администратор
Сообщения: 1103
Зарегистрирован: 18 янв 2012, 01:25
Откуда: Екатеринбург
Контактная информация:

Re: ПРОЧЕЕ

Сообщение admin » 06 июн 2021, 07:41

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

Аватара пользователя
admin
Администратор
Сообщения: 1103
Зарегистрирован: 18 янв 2012, 01:25
Откуда: Екатеринбург
Контактная информация:

Re: ПРОЧЕЕ

Сообщение admin » 06 июн 2021, 07:44

Figma, Sketch, Zeplin - программы для дизайна

Аватара пользователя
admin
Администратор
Сообщения: 1103
Зарегистрирован: 18 янв 2012, 01:25
Откуда: Екатеринбург
Контактная информация:

Re: ПРОЧЕЕ

Сообщение admin » 07 июн 2021, 19:56


Аватара пользователя
admin
Администратор
Сообщения: 1103
Зарегистрирован: 18 янв 2012, 01:25
Откуда: Екатеринбург
Контактная информация:

Re: ПРОЧЕЕ

Сообщение admin » 09 июн 2021, 15:48


Аватара пользователя
admin
Администратор
Сообщения: 1103
Зарегистрирован: 18 янв 2012, 01:25
Откуда: Екатеринбург
Контактная информация:

Re: ПРОЧЕЕ

Сообщение admin » 09 июн 2021, 19:43

принцип SOLID

принцип SOLID

Объяснение

S — Single responsibility principle — Принцип единственной обязанности:
На каждый класс должна быть возложена одна-единственная обязанность.

O — Open/closed principle — Принцип открытости/закрытости:
Программные сущности должны быть открыты для расширения, но закрыты для изменения.

L — Liskov substitution principle — Принцип подстановки Барбары Лисков:
Функции, которые используют базовый тип, должны иметь возможность использовать подтипы базового типа, не зная об этом.

I — Interface segregation principle — Принцип разделения интерфейса
Много специализированных интерфейсов лучше, чем один универсальный.

D — Dependency inversion principle — Принцип инверсии зависимостей:
Зависимости внутри системы строятся на основе абстракций. Модули верхнего уровня не зависят от модулей нижнего уровня. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.
Еще почитать по теме:

Аватара пользователя
admin
Администратор
Сообщения: 1103
Зарегистрирован: 18 янв 2012, 01:25
Откуда: Екатеринбург
Контактная информация:

Re: ПРОЧЕЕ

Сообщение admin » 09 июн 2021, 20:00


Аватара пользователя
admin
Администратор
Сообщения: 1103
Зарегистрирован: 18 янв 2012, 01:25
Откуда: Екатеринбург
Контактная информация:

Re: ПРОЧЕЕ

Сообщение admin » 17 июн 2021, 12:24

Протокольно-ориентированное программирование (POP) – это сборник принципов, концепций и практик, которые придают протоколам более заметную роль в практической разработке на iOS.



Аватара пользователя
admin
Администратор
Сообщения: 1103
Зарегистрирован: 18 янв 2012, 01:25
Откуда: Екатеринбург
Контактная информация:

Re: ПРОЧЕЕ

Сообщение admin » 29 авг 2021, 02:12


Аватара пользователя
admin
Администратор
Сообщения: 1103
Зарегистрирован: 18 янв 2012, 01:25
Откуда: Екатеринбург
Контактная информация:

Re: ПРОЧЕЕ

Сообщение admin » 29 авг 2021, 22:25

Функциональное программирование для новичков на примерах


split - разделить,
map — преобразовать
flatMap - преобразовать с выравниванием (удалением одного уровня вложенности),
filter - отфильтровать,
sorted - сортировать,
reduce - свернуть данные в некоторую структуру с помощью определенной операции

Аватара пользователя
admin
Администратор
Сообщения: 1103
Зарегистрирован: 18 янв 2012, 01:25
Откуда: Екатеринбург
Контактная информация:

Re: ПРОЧЕЕ

Сообщение admin » 11 сен 2021, 11:59



Аватара пользователя
admin
Администратор
Сообщения: 1103
Зарегистрирован: 18 янв 2012, 01:25
Откуда: Екатеринбург
Контактная информация:

Re: ПРОЧЕЕ

Сообщение admin » 13 сен 2021, 21:35

Справочник по swift с примерами
https://swiftdoc.org/

Ответить