vit_r: default (Default)
[personal profile] vit_r
Посмотрел недавний код, выяснилось, что написал функцию на 700 строк.

Всё нормально работает.

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

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

Date: 2018-03-09 10:02 am (UTC)
From: [personal profile] smugastyi_kit
Функция на 700 строк? Ха!
У меня один раз был main() на две тысячи LOC :)

Date: 2018-03-09 05:33 pm (UTC)
juan_gandhi: (Default)
From: [personal profile] juan_gandhi
У меня где-то в коллекции есть файл джавный на 50к строк, из них один метод занимает 25к строк, и состоит из большого свича.

Date: 2018-03-09 05:34 pm (UTC)
From: [personal profile] smugastyi_kit
Ох какие ужасы.

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

Date: 2018-03-09 03:56 pm (UTC)
juan_gandhi: (Default)
From: [personal profile] juan_gandhi
А рефакторить как будете, если что?
А откуда знаете, что правильно написано? (какие ваши доказательства).
А что, нарезать на осмысленные кусочки уже нельзя?

Date: 2018-03-09 05:29 pm (UTC)
juan_gandhi: (Default)
From: [personal profile] juan_gandhi
У меня такое ощущение, что вы слишком долго жили в Германии, и впитали этот их дебильный дух девелопмента, когда динамики никакой нет, зато есть какая-то абсолютная неизменная истина в небесах, данная нам в виде Технического Задания.

И предложение использовать копипасту тоже радует.

Это все древняя культура, которая отсюда смотрится нелепой.

Ну и спасибо за рассказ, конечно. Обычно так в деталях это не вербализуют, а просто сообщают, что единственная истина дана говорящему свыше, в порядке жизненного опыта.
Edited Date: 2018-03-09 05:29 pm (UTC)

Date: 2018-03-09 08:19 pm (UTC)
juan_gandhi: (Default)
From: [personal profile] juan_gandhi
В смысле обижаться? Наоборот, я благодарен, без шуток. Открывают мне глаза на некоторые вещи.

Date: 2018-03-11 07:23 pm (UTC)
From: [personal profile] jamhed
> Зачем делать кусочки, если всё и так прекрасно осмысляется?

Очевидным образом вы на свой код не пытались через полгода смотреть. Write-only, ага.

Date: 2018-03-11 09:04 pm (UTC)
From: [personal profile] jamhed
А правильно это городить функции на 700 строк. А я-то думал что это за люди которые функции с 15 аргументами пишут. Или стейт на 40 переменных.

Date: 2018-03-18 01:57 pm (UTC)
From: (Anonymous)
\\Проще и логичнее держать их в одном контексте.

Вот... какраз думал как бы можно было бы переопределить написание программ,
в смысле САЗЕ, чтобы оперировать контекстами.
Что-то типа литерейт програминга, но в более диалоговой и подерживаемой компом манере.

Date: 2018-03-19 06:40 am (UTC)
From: (Anonymous)
Вообще-то... вы оба странные.

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

И это не бага, а фича -- потому что то же самое существует,
и не только в человеческой технике,
а например и в ДНК...

Ну и вы тоже.
Рефакторить код тела функции -- что там рефакторить? и главное -- для чего?
Я кода не видел, но вроде как верю автору,
что он не овсем тупой и копипастного дублирования там у него нет.
То есть, выделять в функции повтяющиеся куски кода не требуется,
а что ж еще тогда рефакторить?
Просто произвольным образом делить функцию на две, несколько?
Накуа?
Не будет ли это наоборот -- бэд практис?

Date: 2018-03-20 11:17 am (UTC)
From: (Anonymous)
\\\\и иногда он как буриданов осел -- не может решить

\\Не "как" и без "буриданов".

\\Если есть альтернативы, они проверяются или по литературе, или на прототипах. Если альтернатива выбрана плохо, это ошибка дизайна.

По как литературе и по какми правилам?
Вы будете выбирать между тем как написать "++х" или "х=х+1"?
Это я так, чтобы самый просто пример выбрать,
и не скатится к холивару пробелов против табов и т.п.

Не знаю, почему вы не видите,
или считает необходимым не учитывать рефаторинг/стиль как отдельную сущность...


\\и главное -- для чего?

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

Вопрос вообще-то был вашему визави.
Вот есть тело функции, которое, так уже получилось, разрослось на 700 строк...
и нет в нем очевидного, напрашивающегося на рефакторинг:
дублирования кода, деления по смыслу и т.п. -- что его все равно "надо рефакторить"?
А смысл?
Рефакторинг ради рефакторинга?
Даже в ужерб читабельности и пониманию смысла?


А что до ФП... то я вообще не знаю, как они там собираются обеспечивать производительность???
Ну, за пределами "наш компилятор компилирует в натив не хуже Сишного".

В С ведь всегда остается вариант вылизать критическую функцию до предела -- накропать её на асме, с учетом всех кеш-миссов и пайплайнов,
и выиграть иногда даже 10%...

Вот я про КУДА читал, так там вообще все весело, и выигрышы могут быть вообще в разы.

А вот я бы хотел посмотреть на ФП реализацию компилятора для ГПУ...
вот почему ФПшники за ТАКИЕ задачине берутся, а? %)

Date: 2018-03-21 07:06 am (UTC)
From: (Anonymous)
\\Такие мелочи не просто понятны, но и описаны даже в каждом втором стандарте. Не всегда обоснования разумные, но это совершенно стандартно.

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


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

Дык... вот это выделенное и означает,
что рефакторинг вы -- делаете.
Но, в данном случае в нем нет необходимости.

Это ведь был камень в сторону вашего оппонента,
который почему-то подумал что рефакторинга вы не делаете в принцыпе,
и потому вам нужно (голословно, однако) доказывать...
не, не что его таки нужно делать...
а только какой вы ужасный редиска, что не хотите делать рефакторинг. %))

Date: 2018-03-21 11:02 am (UTC)
From: (Anonymous)
\\Я не делаю рефакторинг.

Это понимать так, что вы и текст не редактируете?

Там, переименование переменных -- вот что, вы серьозно хотите утверждать что вот 100% ничего подобного не делаете?


\\Потому что это слово описывает неосознанные попытки улучшений красивости "по запаху".

Почему неосознанные?
Несомненно, некоторая часть рефакторинга, делается на основании представлений о "красивости"... потому что стиль.

Но отнюдь не все.

То же выделение метода... чтобы не ввязыватся здесь в холивар по ООП,
Выделять из тела функции другие функции, устранть дублирование кода -- это несомненно один из видов рефакторинга,
и так же несомненно, характерен не только для ООП, но и обычного структурного и функционального подходов.

А вот, представить себе, как можно редактиовать код ТАК,
чтобы ничего подобного не делать...
Это разве что набирать его в стиле cat > file

Другое дело, что хотелось бы... и давно,
иметь программистам средства анализа и рефакторинга кода,
которые бы (надежно) показывали зависимости между модулями,
"ошибки дизайна", предложение возможных вариантов и т.п.


\\Я нахожу и исправляю ошибки дизайна в полном осознании, что я делаю.

Гуд фор ю.

Date: 2018-03-20 11:08 am (UTC)
From: (Anonymous)
Должен тут признать,
что от вашей с Витом (а почитываю вас обоих довольно давно) дискуссии,
испытал жесткое разочарование.

Вы вроде старшие товарищи,
с опытом и регалиями, до которых мне еще лесом и лесом,
а завязались обсуждать такую чихню,
что и первокурсникам должно быть западло (ну, я наверное не знаю чего там обсуждают первокурсники программисты... я сам механик %) ).

Спасает тут разве что то,
что это довольно тонкие материи.

Действительно, если перенести его на сферу писательства (а кто-то утверждает, что программирование это творческий труд сравни писательскому...),
то
рефакторинг -- он соответствует СТИЛЮ,
а дизайн -- сути, сюжету...

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

А тут, получается на вас классическая дихотомия физиков-лириков.

Вы настаиваете на примате стиля,
что мол всегда нужно писать высоким штилем...
даже если это кома сепарейтед табличка данных... сгенерированная одним процессом для прочтения в другом... и которая может попасть на глаза програмеру только весьма случайно -- то програмер по любому объязан залезть в неё и начать править... там пробелы на табы заменять и вайсе верса,
и так далее?

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


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

Есть только два мнения -- мое, и неправильное (ТМ)


ЗЫ Там уже уважаемый Вит начал обижатся на вольности которые я тут себе позволил,
так что вообще может не расскринить...
да и я сам,
как уже говорил -- разочарован, и лучше мне прекращать подобные (не)дозволеные речи,
пока не полез совсем уже ядреный сарказм тролл-стайл (тоже себе, и тут стиль, да)

Спасибо старики за науку. Буду крутить её на ус. %((


ЗЗЫ И отдельный тут момент. На тему вашего ранее задикларированного разочарования "мурзилками которые ничему учится не хотят".
Да вот... видно ужо у кого и чему учится... неча на зеркало пенять.

Date: 2018-03-21 07:19 am (UTC)
From: (Anonymous)
Аналогии всегда имеют свои ограничения.

И даже так, я там явно указал, что стиль имею в виду в отношении написания текстов... причем тут сценарное мастерство?

Ну а про контекст... может между вами существует, как подводна часть айсберга, обмен глубокими тайными смыслами...
но я могу коментировать только то что вижу и что могу понять.
Увы мне. %(

Извиняюсь

Date: 2018-03-21 11:04 am (UTC)
From: (Anonymous)
Я недостаточно явно указал что то был риторический вопрос.

Как я уже говорил, про стиль я говорил в смысле стиля аписания текста.

Каким образом сюда сценическое искуство... это явный совершеннейший оффтоп

Date: 2018-03-29 12:42 pm (UTC)
mixa_menshenin: (Default)
From: [personal profile] mixa_menshenin
Сценарное мастерство -- это мастерство написания сценариев, то есть художественных текстов, объединенных по контексту и сюжету.
From: (Anonymous)
\\Мне кажется, что я пишу достаточно элементарные вещи. Но они почему-то вызывают странные реакции.

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

Я-то сварщик не местный и всех тонкостей не знаю.
И мои аналогии "рефакторинг -- стиль, дизайн -- сюжет" может быть хромают... и на более чем оджну ногу.
Но по крайней мере у меня есть КМК понимание почему ИМЕННО так.
А вот проблема с пониманием у других -- по ходу та же что и у вас.

Вот и... думаю было бы общеполезно разобратся -- если бы мы смогли договорится до чего-то между собой, то это дало бы нам обоим некие ответы на наши вопросы.
Не так ли?

Так вот... что касается "рефакторинг -- стиль" и вашего замечания про сценическое искуство.

Я как уже говорил/признавал -- ни в каком сценическом искустве не замечен.
Но и посыл мой, касался редактиования текста ТОЛЬКО.
А там... хотя в целом возможная вариативность стилистики потенциально бесконечная (там текст можно и по вертикали, и готическим шрифтом и еще хз как),
но практически... в разрезе изобразительных средств при редактиовании ASCII кода...
стилистическое пространство вполне ограниченное.
Потому, его и имеет смысл обсуждать.

Тогда как дизайн... выраженный в тексте/коде (или вообще графике),
имеет гораздо большую концептуальную глубину.
Описанию дизайна/сценария, уже эти все стилистические изыски, не очень-то и мешают.

Точнее, мешают конечно, если даже элементарные вещи оформить в незнакомоу/неудобной стилистике -- например написать на китайском, да сверху вниз.

То это конечно же помешает пониманию.

Но.
Тут какраз и находится тот самй вопрос -- про конфликт формы и содержания.

Который, если перефразировать в рамках конткекста дискуссии.

Ваша позиция -- стиль/рефакторинг/форма это нинужна -- можно ограничить форму самыми простыми требованиями и этого будет достаточно -- что несомненно ПРАВИЛЬНО, минимализм формы, принцып КИСС они работают,
но...

Вашего же оппонента -- что используя возможности стиля/рефакторинга/вариативности формы -- можно и нужно добиватся соответствия между формой и содержанием, и даже возможо в сторону формы...
тож вряд ли поспоришь... только разве что, с неизбежным при такой постановке вопроса холиваром -- какая форма, какой стиль -- более правильные.

Меня в этом заботит, как уже ранее высказал -- почему вы двое таких умудренных, гораздо более умудренных опытом чем я,
этого не понимаете и не можете договорится...

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

Date: 2018-04-02 06:14 am (UTC)
From: (Anonymous)
\\Я не зря просил не использовать слово "рефакторинг". Если начать называть вещи своими именами, всё становится на свои места.

Герменевтика -- наука очень мощная, факт.
Но,
вы же понимаете что я этого сделать не могу -- потому что именно в этом находится суть противоречия в нашей дискуссии.
И "поменять слова" значит замести все видимые (пускай только мне) противоречия под ковер,
а это уже -- явная арбатовщина.

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


\\Я не зря просил не использовать слово "рефакторинг". Если начать называть вещи своими именами, всё становится на свои места.

Как я указывал. Рефакторинг НЕЛЬЗЯ свести к "ошибкам дизайна".
Иначе, эти ошибки придется траковать ОЧЕНЬ расширительно.
Вплоть до именования переменных, вплоть до применения отступов и пробелов с табами.
Вы что, реально хотите постулиовать, что использование табов(пробелов) вот в этом месте, вместо пробелов(табов) -- это ОШИБКА? %)

Ну, ежели так, то вы попросут ничем не отличаетесь от Хуана Ганди...
просто вы, как приверженцы разных стилистических школ,
никогда не сможете согасится по поводу "что есть правильно и красиво".

Искать тут, в таком случе, какую-то глубину -- попросту глупо. :(
Обычный холивар "табы вс пробелы".


\\Не так. Мне это ничего не даст. Разговор изначально идёт о другом, а объяснять достаточно запутанные вещи, включая графический дизайн или сценарии для анимации мне совершенно влом.

При таком отношении к делу... остается только удивлятся тому что вы сами удивляетесь "почему меня никто не слушает и не понимает"...

Да ведь ровно ПОТОМУ ЖЕ -- "это мне ничего не даст" и "это долго объяснять".


\\Разговор изначально идёт о другом,

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

И зачем для прояснения этого вопроса привлекать "графический дизайн или сценарии для анимации" -- мне совершенно неведомо и неочевидно.
Наоборот. Явный оверкил.

Тем более. Еще раз напомню -- вопрос был о стилистическом оформлении текста в ASCII кодах... причем даже ограниченного их подмножества.
Ну вот причем тут, каким боком графический дизайн???
Тем более, что я и так, заранее, признал что там ДА, там будут существенны отличия.


\\Не советую летать на самолёте, в производстве которого использован принцип KISS

Ну вот, братья Райт летали... и как бы, ничего, неплохо получалось. ;)


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

Ну... вот тут-то я и вижу противоречия... с вашими собственными словами в приведенной выше цитате, и в одном из постов про "нынешние програмеры как папуасы".

То есть, цель "высказатся так, чтобы ОНИ поняли, и возможно прониклись" - таки стоит.
Но... не соответствует (не)явно декларируемой цели.

Это уже психология.

Date: 2018-04-03 06:13 am (UTC)
From: (Anonymous)
\\Это не "видимые", это "кажущиеся". Включая дурацкое "ваше желание победить".

Это еще Свифт высмеивал, тогдашних натурфилософов "если они сталкиваются с чем-то что не могут объяснить, они называют это -- игра природы"...

Я не знаю... постоянно честно в этом признаюсь (за что и "страдаю", да %) как вот -- "И не стоит давать оценку тому, что не понимаешь.") -- получается, что раз САМ признался что чего-то не знаешь, ЗНАЧИТ сам и дурак, неграмотный и ни в чем не разбирающийся, нафиг с таким спорить, он же получается заранее признался что проиграл %))),

например у меня нет ни одного лично знакомого НАСТОЯЩЕГО ученого,
и я не мог наблюдать как они реально делают открытия, приходят к тем или иным выводам.
Но по тому что пишется в литературе -- это делается через АНАЛИЗ и постоянное тестирование собственных посылок.

Большинство же, данное в ощущениях,
и в инете, и так в жизни -- поступают ПРЯМО ПРОТИВОПОЛОЖНЫМ образом.
Оне бронзовеют. %)
Становятся в позу "есть тольео две Правды -- моя... и неправильная".
Настаивают на использовании ТОЛЬКО их определений.
Банют неугодных, сомневающихся.
И т.д., и т.п., и к.з.п.


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

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

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

Но и там все глухо. Мотивация такая же рандомная и не поддается рациональному устаканиванию... %(

Date: 2018-04-03 08:26 am (UTC)
From: (Anonymous)
Просто проанализируем, методом последжовательных приближений,
когда именно редактрпование текста (ака рефакторинг) по вашему убежденгию превращается в "ошибки дизайна"?

1. на уовне расстановки пробелов и переносов -- думаю это можно отбросить,
учтывая что существуют форматеры кода и некоторые даже утверждают что их надо натравливать на код при каждом коммите. %)

2. на уровне редактирования имени переменной?
то есть, если вдруг программист выбрал "неправильное" имя, то это -- ошибка и его вина???
даже если совершенно не было очевидно, что имя нужно будет менять (код написан в одно время, а потом через долгий период времени, скажем месяц, оказалось что его надо расширить).

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

4. на уровне задания структур и классов, там: где какие поля должны быть, акие функции -- здесь уже легче.
Хотя... а как же эксплорэйтив программинг? а если задачи новые, до того не решавшиеся? другой язык, другие библиотеки.
То есть, изучение того как оно работает -- это тоже "ошибки"?
То есть, получается что программист-кодер, в соответствии с вашими воззрениями -- кругом ошибается, чтобы он не делал. Такой вот патологический неумеха. %)
Априорная установка так сказать...
ну, в принцыпе, в режиме "человек -- источник всех ошибок" как инженерного принцыпа можно было бы даже согласится.

5. на уровне вообще структуры проекта...
то есть, если мы создаем новый проект, а потом оказывается что существующие подходы/структуры нас не устраивают...
или например делаем прототипирование "на выброс",
то это тоже "ошибки"? %)
Ну, в таком случае, тут тоже все довольно понятно -- и сходится тютелька в тютельку с обычным эфэктно-мэнагерским "мы не делаем рефакторинг, потому что нам нужно добавлять функционал".
Ну или кондово-програмерское "Пиши код, б*ь!". %)
Тоже вполне понятно.

Date: 2018-04-03 02:52 pm (UTC)
From: (Anonymous)
\\Это называется "Спор сам с собой". Спасибо, но вся система заблуждений мне уже давно прекрасно известна.

"...дабы дурость его была видна".
Я свои "заблуждения" не скрываю под маской "я это знаю, но никому не скажу".
Потому что считаю это контр-продуктивным -- но пейн, но гейн. %)
Только и всего.

ЗЫ Наоборот, много раз встречал людей, и в реале в том числе, которые попрекали меня "заблуждениями"... а сами при это... ну да, не будем о грустном.


\\Редак что? Если было "редактирование", то, вообще, какой-то бред получается.

Замена имени переменной -- это не редактироование?

Или вы уже на том уровне абстракций,
что у вас уже как в (xkcd: Real Programmers https://xkcd.com/378/)
и код вам бабочки "набивают".

Date: 2018-03-10 03:01 am (UTC)
gxachaturov: (Default)
From: [personal profile] gxachaturov
Мне кажется, что подобное можно только в очень тепличных условиях. Либо у над вами нет начальства и внутри-корпоративной конкуренции, либо начальство вам сильно доверяет. Однако, случись что с исполнителем, передать другому человеку на сопровождение функцию в 700 строк -- проблематично.

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

Иначе это все мина замедленного действия для бизнеса.

Date: 2018-03-11 01:20 pm (UTC)
From: [personal profile] anonim_legion
>передать другому человеку на сопровождение функцию в 700 строк -- проблематично.

Ничего страшного, передать можно. Берём - и передаём. А он её - не поддерживает, потому что не понимает, но она и так неплохо работает, без поддержки.

Очевидно

Date: 2018-03-21 12:15 pm (UTC)
From: (Anonymous)
\\Если писать правильно, сложность растёт линейно от количества текста.

Очень небольшое количество текстов, для которых сложность растет "линейно от количества текста".
Например список покупок... но даже и в нем, все усложняется,
если например выясняется что некоторые его составляющие являются составляющими рецепта, в котором возможна вариативность.

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

Гуд фор ю, если вы работаете в такой области где именно такие программы.

Date: 2018-03-11 08:32 pm (UTC)
ext_646638: (Default)
From: [identity profile] rdia.livejournal.com
Ну всё, реально, зависит от того, что, где и как. В общем, не надо делать из еды культа. Но, как правило, функции длиннее экрана понимаются тяжело.

Profile

vit_r: default (Default)
vit_r

February 2026

S M T W T F S
12 34 567
8 91011121314
15161718192021
22232425262728

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Feb. 10th, 2026 02:49 am
Powered by Dreamwidth Studios