Вход | Регистрация
    1  2  3  4

Зазеркалье: 1С:Исполнитель

Зазеркалье: 1С:Исполнитель
Я
   PR
 
03.06.20 - 18:08
1. Ждем32% (7)
2. Не ждем32% (7)
4. Свое мнение27% (6)
3. А что это?9% (2)
Всего мнений: 22

Ну что, даешь девопс от 1С!
https://wonderland.v8.1c.ru/blog/1c-ispolnitel/
   Garykom
 
301 - 07.07.20 - 09:19
Интересно компилятор а не интерпретатор 1С пользовался бы спросом?
Нечто по типу Golang чтобы в бинарники достаточно шустрые и компактные.
   Asmody
 
302 - 07.07.20 - 09:44
(301) Ты представляешь, сколько какая-нибудь УТ11 собираться будет? Кнопку подвинул и на 2 часа компиляции
   Asmody
 
303 - 07.07.20 - 09:46
На деле в учете не так много задач, которые требуют прям вычислительной мощи. Основное время всё равно на банальную выборку и преобразование данных уходит.
А вот типобезопасность, хотя бы, очень не помешала бы.
   Ненавижу 1С
 
304 - 07.07.20 - 09:49
Наверное это всё будет в FreeRAD
   Fragster
 
305 - 07.07.20 - 10:39
(299) я потестил ванскрипт и перешел на него с баша
   Serginio1
 
306 - 07.07.20 - 18:11
(302) Ну проекты на C# собираются не так уж и долго. Правда как правило куча библиотек, которые не изменяются.
Проблемы времени компиляции обычно с C++ со специализацией шаблонов. Но в том же .Net компиляция двойная сначала в байт код, затем джитится в машинный.
Есть .Net Native это UWP. Там уже используется С++ компилятор и хорошо оптимизируется в том числе с использованием  SIMD инструкций. Да компиляция более долгая. Но не 2 часа.
1С по уму нуно переходить на сборку мусора. Тот же .Net Native хотя и компилируется сразу в машинный код, но сборка мусора такая же как и в среде .Net
   rphosts
 
307 - 07.07.20 - 18:13
(305) какие плюсы?
   rphosts
 
308 - 07.07.20 - 18:19
(306) быстро - это борландовский компилятор турбо-паскаля... на ХТ компиляция летала!!!
   Злопчинский
 
309 - 07.07.20 - 18:21
(308) хм.. кто сейчас помнит про борланд...
   rphosts
 
310 - 07.07.20 - 18:54
(309) вот прикинь, в прошлой конторе было в штатном 3 вакухи дельфинов (дельфи).
   strange2007
 
311 - 11.08.20 - 09:03
Коллеги, подскажите, а переход на эти новшества, что даст бизнесу? Такой скриптовый язык куда можно применить, что бы бизнес, например, лучше считал деньги?
   Garykom
 
312 - 11.08.20 - 09:08
(311) Смотря какому бизнесу.

Который пользуется 1С даст лишние расходы в обмен на фирменность от производителя.
А бизнесу по продаже 1С вытеснение бесплатного OneScript и замена на коммерческий Экзекутор
   strange2007
 
313 - 11.08.20 - 09:19
(312) С другой стороны зайду - что даёт бизнесу ОСкрипт?
Это не стёб, я просто пытаюсь понять, что на этих штуках можно сделать такого, что бы директор такой сказал "Вах! На тебе денег на новый доширак!"
   Garykom
 
314 - 11.08.20 - 09:25
(313) Автоматизация различных операций с серверами, базами 1С, платформами 1С и юзверями.
   Garykom
 
315 - 11.08.20 - 09:27
(314)+ Ну например юзер заводится в домен - и автоматом скрипт прописывает его во все нужные базы 1С.
Или не во все а по шаблону от подразделения/должности в базе ЗУПа.

Короче примеров дофига, юзер в отпуске/уволен - автоматом учетка в 1С блочится.
   strange2007
 
316 - 11.08.20 - 09:31
А интерфейсная часть у ОСкрипта есть? Что-то читаю и пока там только консоль попадается. Понимаю, что это из разряда фантастики, но может там можно сделать, например, получение простого отчёта без 1С? Начальнику зачем вся платформа, если он только ексель разглядывает?
Более предметно: Можно через ОСкрипт сделать так, что бы было какое-то предупреждение за 2 дня до дня рождения главного бухгалтера?
   ptiz
 
317 - 11.08.20 - 09:32
Я до сих пор нигде не нашел главного: этот Испольнитель требует какие-то лицензии или нет?
   strange2007
 
318 - 11.08.20 - 09:34
Ещё вопрос: если 1С:Исполнитель пойдёт в народ, то он не заглохнет по причине "он не приспособлен для жизни", "тяжёлый зараза", "дорогой слишком хад" или ещё из-за чего либо?
И какие перспективы у ОСкрипта в плане живучести?
   Garykom
 
319 - 11.08.20 - 09:35
(316) https://oscript.io/docs/page/libraries
https://github.com/oscript-library

есть интерфейсная хотя она нафик не нужна
и ты путаешь что такое 1скрипт - это не работа с данными в 1С и не замена 1С

Это создание бинарных консольных утилит на языке программирования 1С, для тех кто не смог даже батники освоить ))
   Garykom
 
320 - 11.08.20 - 09:42
(318) у ОСкрипта лично для меня только один недостаток - оно на C#/.Net написано, вместо чего то более низкоуровневого и легко переносимого.
Вот если 1С:Исполнитель в этом плане лучше и будет развиваться то вполне пойдет в народ.
Лицензирование думаю там не будет сильно напряжное ибо есть бесплатный опенсурсный конкурент.

А насчет живучести ОСкрипта то все зависит от поддержки и развития автором и сообществом. Если там будут фишки лучше чем в Исполнителе то почему оно сразу загнется.
   Garykom
 
321 - 11.08.20 - 09:48
(320) Хотя 1С:Исполнитель нифига в этом плане не лучше - он требует установки JRE
   strange2007
 
322 - 11.08.20 - 09:51
(319) Батники знаю, но использовать их не люблю, потому что с ними очень резко уходишь в непроглядную чащу и в итоге проект забрасывается.

(320) >> Если там будут фишки лучше чем в Исполнителе то почему оно сразу загнется.
Как обычно, станет скучно без денег.
А вот прослойка из C# сразу всё портит. Значит опасно глядеть в сторону этих скриптов
   Garykom
 
323 - 11.08.20 - 09:56
(322) Прослойка из Java ничуть не лучше
Я бы предпочел "исполнитель" с исходниками на Go или Rust
   Fragster
 
324 - 11.08.20 - 10:08
(320) главная фишка оскрипта - язык 1с. 1сЖисполнитель - это адовый адок.
   strange2007
 
325 - 11.08.20 - 10:18
(323) Именно так и есть. Поэтому пока что остаюсь на PureBasic-е. Просто, мелко и быстро. Для мелких вещей самое оно.
Правда там трудно разобраться другому без опыта, но это уже не обсуждается
   Garykom
 
326 - 11.08.20 - 10:35
(325) PureBasic для меня имеет фатальный недостаток - денег хотят
На синтаксис глубоко мне пофиг банально есть аналоги для меня в виде Lazarus или Golang
   strange2007
 
327 - 11.08.20 - 11:24
(326) >> фатальный недостаток - денег хотят
В точку! За 800 строк многое не сделаешь, но для мелкотни почему бы и нет.
Но С++ слишком тяжёлый для мелкого, fasm вообще неподъёмный
   Ненавижу 1С
 
328 - 11.08.20 - 18:39
(324) "язык 1с" уже пожил своё
   Fragster
 
329 - 11.08.20 - 19:52
(328) ну если и обновлять, то явно не на то что в 1с:исполнитель же
   Serginio1
 
330 - 11.08.20 - 21:20
(320) Вот чем тебе C# то не угодил?
Насчет низкоуровнего. Например Unity компилируют C# в нативный код. Есть .Net Native, CoreRT.
Сейчас работает под любые платформы. И ускоряется https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-5/

После перехода на кроссплатформенность язык и платформа нехило развиваются. Плюс Блазор итд.
Так, что .Net сейчас одна из самых перспективных платформ.
(322) И чем же это портит? Как раз в этом то и есть преимущество.
Кроме того .Net можно использовать в 1С напрямую.
 
 Рекламное место пустует
   palsergeich
 
331 - 12.08.20 - 00:50
(320) Не загнется, точнее если изагнется то не сразу.
там на оскрипте уже туева куча легаси живет, так как разумной альтернативы долгое время не было.
   palsergeich
 
332 - 12.08.20 - 00:51
(319) Дело даже не в батниках.
на оскрипте удобненько и есть мощные либы.
   Garykom
 
333 - 12.08.20 - 08:45
(330) C# мне нравится как и сами классы .Net - это один из лучших языков и прекрасные фреймворки.
Не нравятся приколы (ой нужная версия .Net не стоит, ой ее нету для этой устаревшей операционки и т.д.) и глюки (все стоит что тебе надо какого хрена глючишь) разные.
   hi1C
 
334 - 12.08.20 - 09:58
Мы ругаем язык 1С, для это есть причины, но, возможно благодаря его простоте, я, например, никогда не сталкивался с невозможностью разобраться с чужим решением. То есть, бас фактор не наблюдаем. Хорошо это или плохо - другой вопрос. Работадателям хорошо, всяким "наседкам" плохо.
   Serginio1
 
335 - 12.08.20 - 10:28
(333) Ну их сейчас 3 штуки. .Net 3.5 под XP, .Net 4.5-4.8 под Win 7 и выше.
И Core под Win 7 и выше. При этом в Core в отличии от фреймворка нет GAC и можно настроить автономное развертывание.
При публикации автономного развертывания (SCD) пакет SDK для .NET Core создает исполняемый файл для конкретной платформы. Публикация SCD включает в себя все необходимые файлы .NET Core для запуска приложения, но не включает машинные зависимости .NET Core. Эти зависимости должны присутствовать в системе перед запуском приложения.

https://docs.microsoft.com/ru-ru/dotnet/core/deploying/deploy-with-cli
   Garykom
 
336 - 12.08.20 - 10:39
(334) >благодаря его простоте, я, например, никогда не сталкивался с невозможностью разобраться с чужим решением

Есть куча конфигураций где даже идеально зная язык и платформу хрен разберешься в короткие сроки
   Serginio1
 
337 - 12.08.20 - 11:26
(334) Именно из-за его простоты там такая куча наворотов и. Правда и в ООП тоже тяжело разобраться без отладки, но при этом код лаконичен и главное типизирован.
Поверь мне на C# приходится разбираться тоже с огромными количеством кода и это проще чем в 1С, где для универсальности из-за отсутствия ООП используют утиную типизацую и прочие костыли
   hi1C
 
338 - 12.08.20 - 15:49
(336) Возможно я не сталкивался с по настоящему сложными решениями. Я дорабатываю в основном самописки.
   Конструктор1С
 
339 - 12.08.20 - 16:47
ИМХО, все эти ООП и строгие типизации хороши когда нужно забубенить сервисный механизм. Например, разобрать/собрать XML с ООП намного удобнее. А вот именно бизнес-логику удобнее писать функционально и с неявной типизацией. А-ля 1с
   Конструктор1С
 
340 - 12.08.20 - 16:48
Но исполнитель это какой-то кастрат получился. Java без ООП...
   Serginio1
 
341 - 12.08.20 - 16:59
(339) Чем это лучше? Для примера в Вэбе TypeScript набирает популярность именно за счет типизации.
Тот же Linq очень удобен для запросов. Проблемы возникают только в универсальных отчетах.
Но и там можно использовать кодогенерацию и кэширование запросов.
В конце концов например в C# dynamic. То есть тот же C# он может быть и строго типизирован, и там где нет может быть с динамической типизацией.
Кстати в том же исполнителе они пошли по пути типизации как в TypeScript
   Конструктор1С
 
342 - 12.08.20 - 18:47
(341) лаконичностью написания лучше. По-моему даже некорректно сравнивать DSL-язык (1с) и язык общего назначения (C#). Последний создавался не для написания бизнес-приложений
   Serginio1
 
343 - 12.08.20 - 23:31
(342) C# очень универсальный язык. Один только Linq чего стоит. Что в 1С сильно не хватает и лаконичность побьет 1С однозначно, а учитывая типизацию то выиграет и по скорости написания кода. Так что ты здесь неправ.
Куча конструкций упрощает написания кода. Про отсутствие замыканий вообще промолчу.

Да и 1С DSL то очень сложно назвать. Единственно это в одном модуле написание серверного и клиенсткого кода. Да и то на C# это решается через условную компиляцию и кодогенерацию https://devblogs.microsoft.com/dotnet/introducing-c-source-generators/

C# это не только язык но VIsual Studio c плагинами которые ты сам можешь написать и использовать.
   Конструктор1С
 
344 - 13.08.20 - 05:31
(343) в этом-то и разница. Универсальный VS. узкозаточенный. Про скорость написания кода очень спорно. Сам код может и пишется быстрее, за счет шибко умной IDE, но для решения аналогичной задачи на C# того кода придётся написать намного больше, нежели на 1с
   Конструктор1С
 
345 - 13.08.20 - 05:38
"Один только Linq чего стоит"

Ну и в чём его преимущество перед 1сным "метаданные + язык запросов + конструктор запросов"? Он позволяет за несколько кликов мышкой написать сложные запросы?
   Serginio1
 
346 - 13.08.20 - 11:47
(345) Так и в C# метаданные есть. Если хочешь конструктор есть LinqPad https://www.linqpad.net/
Все метатанные легко переносятся на EF Code First
http://catalog.mista.ru/public/402038/
http://catalog.mista.ru/public/402433/

При этом ты получаешь типизированный результат.
А если тебе нужно сделать запросы по различным условиям, то тут либо склейка кода либо лепить условия внутри запроса.
В Linq ты можешь использовать несколько запросов делать соединения итд
   Конструктор1С
 
347 - 13.08.20 - 14:26
(346) кхм...

SELECT ... FROM (SELECT ... FROM (SELECT ... FROM (SELECT ... FROM (SELECT ... FROM (SELECT ...

это ты серьёзно?
   Кирпич
 
348 - 13.08.20 - 15:16
Ловите LinqМАНА!!!
   Serginio1
 
349 - 13.08.20 - 16:56
(347) Это ты про что? Переведи
   Конструктор1С
 
350 - 13.08.20 - 17:21
(349) про месиво из вложенных запросов. Неужели linq не умеет ни во временные таблицы, ни в табличные выражения?
   Лефмихалыч
 
351 - 13.08.20 - 17:24
это противоестественно
но прикольненько

4. Свое мнение
   Serginio1
 
352 - 13.08.20 - 17:41
(350) Linq это абстракция. Изначально он был к коллекциям, потом пришпондорили к SQL.
Есть несколько множество фреймворков Entity  Framework, Linq2DB итд.
Суть их в том, что по IQueryable составлять запросы. Например нет особого смысла в во временной таблице если можно применить отдельный запрос по подзапросах.
Например Linq2DB может использовать CTE https://linq2db.github.io/articles/sql/CTE.html
аналитические функции
https://linq2db.github.io/articles/sql/Window-Functions-(Analytic-Functions).html

Чего сильно не хватает в 1С.

Практически можно все!
   Ненавижу 1С
 
353 - 13.08.20 - 20:41
у LINQ есть как минимум три плюса перед запросами 1С:

1. Он контролируем в Compile-time: метаданные, проверка и вывод типов
2. Он переиспользуемый: LINQ-выражение можно передать в функции, которые могут их дополнить
3. Он расширяемый: Можно расширять своими методами, которые ретранслирует новые недостающие вещи SQL
   arsik
 
354 - 13.08.20 - 21:22
(353) По ходу ты сейчас СКД описал.
   Asmody
 
355 - 13.08.20 - 21:24
(354) ну нет. Ты не можешь без танцев с бубном взять кусок СКД и засунуть его в другую СКД.
   Ненавижу 1С
 
356 - 13.08.20 - 21:51
(354) ну точно
1. Нет. Можно получить невалидный код, который вылезет только в запуске
2. Очень сложно получается
3. Он не делает это на SQL
   Ненавижу 1С
 
357 - 13.08.20 - 21:56
и я не говорю, что в LINQ нет проблем
1. неоптимальные запросы, как у любой абстракции
2. если быть честным, то и он пропустит запрос, который не валидный. Например Comment.Length - а там внезапно неограниченная строка и если тип неспециальный у Comment, то компиляция пройдет
3. разное поведение в Linq-for-SQL и Linq-for-Object
   Asmody
 
358 - 13.08.20 - 22:20
(357) а Linq оно же над стримами? Распараллеливается и все такое?
   acht
 
359 - 13.08.20 - 22:36
(357) Это, кстати, готовые вопросы для собеседования. Понимаете-ли вы, как. И какие ограничения у. Разные должности, разные зарплаты, процесс идет, продукт продается...

А свое мнение по поводу правильности - ну, ты можешь свернуть его в трубочку и =)

Вот интересно, что будут делать апологеты типа Смирнова, через полгода, с появлением новой концепции ORM, какого-нибудь "ObjektAlchemie". Переметнутся, признают свое устарение, будут с пеной у рта вспоминать молодость?
   Ненавижу 1С
 
360 - 13.08.20 - 23:17
(359) так-то тут "форум", не надо никому указывать, что делать с мнением
а иначе - расходимся, обсуждать нечего: про плюсы 1С в официальной литературе от вендора почитать можно
 
 Рекламное место пустует
   Конструктор1С
 
361 - 14.08.20 - 05:14
(352) "Например нет особого смысла в во временной таблице если можно применить отдельный запрос по подзапросах"

Это когда у тебя небольшая БД. Когда БД вырастает, все эти соединения подзапросов с подзапросами, построенными на подзапросах, начинает выходить боком
   Конструктор1С
 
362 - 14.08.20 - 08:04
(360) пишет юзер с ником Ненавижу 1С)
   Serginio1
 
363 - 14.08.20 - 10:29
(361) Угу большинство в 1С временными таблицами пользуются из-за удобства использования, что бы один и тот же запрос не плодить внутри подзапросов.
В Linq2DB есть поддержка временных таблиц.
   polosov
 
364 - 14.08.20 - 10:52
(363) Временные таблицы не для удобства использования. Использование ВТ помогают СУБД (в частности MS SQL) строить более оптимальный план запроса. С вложенными таблицами есть некоторые сложности с этим.
   Serginio1
 
365 - 14.08.20 - 11:45
(364) Я прекрасно понимаю для чего нужны временные таблицы. А так же вижу как они используются.
Вплоть до использования запроса к таблице значений, для сложных отборов итд.
http://catalog.mista.ru/public/371762/

А с этим и Linq прекрасно справляется. Нет в 1С замыканий!
   Serginio1
 
366 - 14.08.20 - 12:10
365 + Вот пример Linq to DataSet аналог таблицы значений
https://www.tutorialspoint.com/linq/linq_dataset.htm#:~:text=Below%20is%20a%20simple%20example,the%20means%20of%20join%20clause.
   vechiy
 
367 - 14.08.20 - 12:28
Ну чего, кто-то что-то сделал полезное с помощью него?
   Eiffil123
 
368 - 14.08.20 - 12:31
(302) В java кстати давно уже изобрели компиляцию на уровне классов, поправил один класс, только он и компилируется.
   Конструктор1С
 
369 - 14.08.20 - 12:33
(365) бро, я конечно дико экскюзми, но почему ты пишешь код а ля джуниор-стайл? Вроде бы в программировании уже давно, разрабатываешь на C#, а там clean code, clean architecture и вот это вот всё. Должен же знать, как пишется хороший код. Ни разу не хейтерствую. Просто интересно, почему не развиваешь скиллы кодонаписания?
   polosov
 
370 - 14.08.20 - 13:41
(369) Это признак одиночки. При работе в команде за такой код могут побить.
   Serginio1
 
371 - 14.08.20 - 14:04
(369) Всегда учусь и стараюсь улучшать свои навыки.
(370) Меня побить сложно. В зал хожу, на велосипеде катаюсь и вешу почти 100 кг. Но на продуктивную критику не обижаюсь и стараюсь совершенствоваться!
Нет предела совершенства! Работаю кстати к коллективе, но на C#
   Конструктор1С
 
372 - 14.08.20 - 14:26
(370) согласен. Обычно одиночки подзастревают в профессиональном уровне. Сам таким когда-то был

(371) наверно у вас коллектив совсем маленький и/или нет больших проектов. На серьёзных проектах такой code-style уже давно получил бы обратную связь от коллег в виде потоков возмущения
   Serginio1
 
373 - 14.08.20 - 15:02
(372) Этот код был написан лет 15 назад под 7.7 , адаптирован под 8.3 на скору руку. Тогда работал один и особо не занимался рефакторингом.
И делать выводы по одной странице кода все таки не стоит. И предполагать кто, где, и чем занимается.
   Serginio1
 
374 - 14.08.20 - 15:05
373+ но я очень часто пользовался http://catalog.mista.ru/public/371762/
для группировки данных и отборов в таблице значений для кучи задач.
Кому надо разберется.
   Бертыш
 
375 - 16.08.20 - 08:58
(0) 1C фактический расписалась в том в чём я их обвинял в самом начале выхода восьмёрки, а именно в неумении и непонимании в части дизайна языка программирования, то есть выбора конструкций и операторов языка. У меня дома есть пепельница. Я наклею на неё логотип 1С. Пусть она будет 1С совместима, ну или я так буду думать

4. Свое мнение
   Конструктор1С
 
376 - 16.08.20 - 09:17
(374) рефакторинг не делаешь что ли?
   Serginio1
 
377 - 16.08.20 - 11:26
(376) Я много чем занимаюсь, в том числе рефакторингом кода и не только своего в сложных алгоритмах, для упрощения понимания кода.
А приведенный код достаточно прост. В нем разобраться может любой программист. И тратить на это время нет смысла.
Если тебе не нравится ну извини.
   Конструктор1С
 
378 - 16.08.20 - 12:12
(377) разбираются и не в таком коде. Разбираются и в куда более сложном и уродливом коде. Но это всё вынужденно. В твоём коде придётся разбираться 10 минут (условно), а будь он написан хорошо, понадобилось бы полминуты. Своим "ай, и так сойдёт" ты фактически породил лишние трудозатраты для других программистов, которые будут читать код после тебя
   DTX 4th
 
379 - 16.08.20 - 12:43
Facepalm

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

2. Не ждем
   Serginio1
 
380 - 16.08.20 - 13:03
(378) Ну сочувствую тебе. Там суть сортировки слиянием. Да может и стоило написать комментарии, но сортировку слиянием знают все. Там единственно проблема на 7 ке  различались сортировка в таблице значение и сравнение на больше меньше.
Но для 8 ки код легко читаем зная алгоритм сортировки слиянием.
   Serginio1
 
381 - 16.08.20 - 13:20
380 + Кстати эта одна из моих первых публикаций. И многие жаловались на сложность кода.
Я это учел, и стал стараться писать более понятный код. К последним публикациям стало значительно меньше нареканий
http://catalog.mista.ru/profile/82159/objects/
   Конструктор1С
 
382 - 16.08.20 - 13:56
(380) вот именно в этом и проблема. Чтобы понять, что делает этот код, нужно провалиться внутрь и много раз побегать глазками туда-сюда. Хороший код не заставляет читающего вникать в лишние подробности, а плохой вынуждает перечитывать его весь, вновь и вновь, с немалым усилием продираясь через хитросплетения. В хорошем коде метод сам "кричит" о том, что же он делает.

Допустим, дорабатываю я логику расчета зарплаты. В данный момент мне интересно начисление сверхурочных. Весь алгоритм расчета 40 тысяч строк. И мне нужно найти код, который необходимо изменить. Встречаю такой вызов:

ИсключитьСотрудниковПолностьюОтработавшихНормуПоГрафику(ТаблицаНачислений);

собственно, мне сразу становится понятно, что делает данный алгоритм (да, внутри может быть и куча побочной логики, но это уже отдельная тема). И я понимаю, что внутрь этой процедуры мне заглядывать незачем. А если бы было написано твоим code-style? Я бы наткнулся на что-то такое:

ИсключитьИзТЗЛишних(Таблица);

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

Ты чувствуешь, как трудозатраты на анализ кода моментально возросли? И я не придираюсь и не утрирую. Наверно каждый опытный программист может поведать истории, как он потратил неделю на добавление в программу нескольких десятков строк кода. Тут "спасибо" небрежности предшественника, который экономил символы на именах переменных и методов. К слову, невнятные имена далеко не единственное, что гробит код
   Конструктор1С
 
383 - 16.08.20 - 14:06
+(382) отдельно стоит заметить, что если писавший код "красафчик", и имена переменных/методов в его коде четкие и лаконичные, то с большой долей вероятности нужный код отыскался бы через глобальный поиск по конфигурации.

ЗЫ любой программист в процессе разработки не столько пишет код, сколько читает (и свой и чужой код). Поэтому всегда нужно стремиться написать как можно более понятный [для других] код
   Вафель
 
384 - 16.08.20 - 14:07
у него просто мысль бежит далеко впереди
   Serginio1
 
385 - 16.08.20 - 15:35
(382) Еще раз если знаешь алгоритм сортировки, то хватит беглого просмотра кода.
Если ты его не знаешь, то лучше обратиться к учебникам.
Еще раз прочитай 381. И посмотри эволюцию кода, а не суди по первой публикации.
Я понял, что многие не знают о сортировки слиянием и стал писать более качественный и комментируемый код.

Опять, же что касается кода, то например в Visual Studio, я легко могу просмотреть комментарий к методу и код на той же странице внизу метода.

Проблема 1С ников в том, что среда разработки очень отстает от VS.
   Вафель
 
386 - 16.08.20 - 15:37
начни хотя бы с выравнивания кода
одно это дает +50 к читаемости
   Serginio1
 
387 - 16.08.20 - 15:57
385+ Проблема не только в среде но и в отсутствии типизации в 1С. Ты не можешь посмотреть что это за метод и откуда.
А вот в 1С:Исполнитель как раз и вносить аннотацию типов как в тайпскрипт. Плюс возможность редактировать в Visual Code/
Она хоть и отстает от Visual Studio но значительно лучше чем 1С конфигуратор.
После Visual Studio залезаешь в конфигуратор сразу ооочень сильно неудобно разбираться в коде.

(386) Код был выравлен. Просто при вставке на страницу он покурочился и приходилось вручную выравнивать. Я потом стал применять PASTEBIN.COM для правильного отображения
   Конструктор1С
 
388 - 16.08.20 - 16:08
(385) интересно, и что же тут хоть отдаленно намекает на сортировку слиянием?

глСгруппироватьТзПоПолю()

это чрезвычайно ёмкое название так и заставляет заглянуть внутрь, ибо иначе ну совсем никак... Про что я тебе и пытаюсь объяснить
   Ненавижу 1С
 
389 - 16.08.20 - 16:10
(385) только массивы хранят объекты произвольного типа. На этом типизация заканчивается
   Конструктор1С
 
390 - 16.08.20 - 16:18
(385) "я легко могу просмотреть комментарий к методу"

Такой надобности даже не возникло бы, будь название метода удачно подобранным. К тому же комментарии:
- далеко не у всех методов
- имеют свойство становиться неактуальными
- зачастую содержат какую-нибудь туфту, которая ничего не объясняет, а только ещё больше запутывает
Хороший метод с удачно выбранным именем не нуждается в комментарии. По-сути код это лучшая документация, самая актуальная и самая точная. Надо лишь написать код так, чтобы он сам себя документировал
   Serginio1
 
391 - 16.08.20 - 16:28
(388) Прошу прощения. Там в статье в исходниках есть сравнение 2х ТЗ там используется алгоритм слияния.
В глСгруппироватьТзПоПолю() глСгруппироватьТзПоПолям используется элементарная сортировка и сравнение 1 элемента в группе с последующими и копирование этих записей в отделную ТЗ. Результирующая ТЗ имеет вид "Поля группировки" и тз с записями содержащие эти поля группировки.
Еще раз это была первая статья. Потом я исправился. Но посчитал, что код элементарен и не стал его оформлять должным образом.
В дальнейшем я исправился!
   Serginio1
 
392 - 16.08.20 - 16:34
(390) Я не согласен. А комментарии к аргументам? Особенно когда их под десяток?
Или ты и аргументы будешь писать типа СотрудникДляИсключенияПолностьюОтработавшихНормуПоГрафику.
Кроме того есть куча параметров по умолчанию.
А вот для тебя такой подход правильный потому, что нет возможности в конфигураторе посмотреть пояснение к коду.
   Конструктор1С
 
393 - 16.08.20 - 17:00
(392) 10 аргументов в методе тоже указывают на плохой код. Принципы написания хорошего кода придуманы не мною, и не для конфигуратора 1с. Они как раз "выстраданы" на этих ваших тру-языках, и не теряют актуальности во времена умных IDE

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

МинимальноеПоложительноеЧисло(Массив)

вроде бы понятно, откуда возьмёт и что вернёт функция


МинимальноеПоложительноеЧисло(МассивДляПоискаМинимальногоПоложительногоЧисло)

тут уже лишнее, бессмысленное пояснение
   Serginio1
 
394 - 16.08.20 - 17:56
(393) Ошибаешься. Какой аргумент правильно поставить тоже нужно знать и его тип.
В том же C# для очень сложных методов проще создать класс, что бы не передавать кучу параметров и разделять метод на множество коротких.
Что касается  МинимальноеПоложительноеЧисло то и Min(uint[] array) значительно лаконичнее и информативнее.
Кроме того в 1С при вызове метода через точку нет интеллисенса для модуля или если не указан тип. И можно просто элементарно ошибиться набирая длинное название метода.

Поверь программируя на том же C# значительно быстрее разбираешься с кодом чем в 1С. После C# разбираться с кодом 1С одно мучение. (английский еще и лаконичнее)
Поэтому нужна и типизация и более продвинутый редактор кода.
   Конструктор1С
 
395 - 16.08.20 - 18:27
(394) "то и Min(uint[] array) значительно лаконичнее и информативнее"

не-а, присмотрись внимательнее к моему названию метода, оно содержит важное дополнение. К тому же, когда ты будешь читать код, ты увидишь Min(array), а не Min(uint[] array) из заголовка метода

"И можно просто элементарно ошибиться набирая длинное название метода"

Ну это вообще какая-то надуманная проблема
   Конструктор1С
 
396 - 16.08.20 - 18:32
А манера писать короткие имена (экономить на символах) это ментальная ловушка, в которую попадают многие программисты. Да, можно дать короткое лаконичное название методу или переменной, но для этого нужно хорошенько подумать. В большинстве случаев "короткое имя" = "невнятный огрызок"
   Конструктор1С
 
397 - 16.08.20 - 18:36
Против типизации ничего не имею. Она действительно полезна, но не панацея. Идеяльно было бы, если бы в 1с можно было по желанию типизировать аргументы методов

ПроверитьДатуПриёмаНаРаботу(ТаблицаЗначений сотрудники)
тут тебе и контекстная подсказка, и проверка типа
   Serginio1
 
398 - 16.08.20 - 19:38
(395) Увижу Min(array) а array  уже имеет тип.
Насчет надуманной проблемы. Из-за того, что нет статической типизации проверки кода нет и
очень часто возникают ошибки у из-за сильного ветвления кода в некоторую часть она может попасть раз в пятилетку, а там элементарная синтаксическая ошибка.
Это проблема всех языков с динамической типизацией, ибо невозможно покрыть все тестами.
(396) Ну вот коммунисты применяли сокращения. Абырвалг и прекрасно до сих пор живем.
Проблема иногда читать код с длинными именами это тоже факт.
Нужна золотая середина.
И имея подсказку в виде комментария в студии это не проблема.

ПроверитьДатуПриёмаНаРаботу(ТаблицаЗначений сотрудники)
Про это то и речь. В том же TypeScript ты можешь написать
ПроверитьДатуПриёмаНаРаботу(сотрудники:ТаблицаЗначений)
так и 
ПроверитьДатуПриёмаНаРаботу(сотрудники)
При этом они написали аннотации к куче JS кода.
   acht
 
399 - 16.08.20 - 20:14
(397) (398) Вас обоих надо расстрелять за использование буквы "ё" в идентификаторах.
   acht
 
400 - 16.08.20 - 20:16
(396) > А манера писать короткие имена (экономить на символах) это ментальная ловушка, в которую попадают многие программисты.

Ты это, между прочим, пишешь изобретателю идентификатора "Ъ" в своей нетленке с сишарпом *сарказм*
  1  2  3  4

Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.