VetCAD

20 самых плохих практик работы в AutoCAD

   0 оценок

размещено: 27 Сентября 2016
обновлено: 27 Сентября 2016

На самом деле это не своя статья, а реакция на чужую :) Которая опубликована в http://www.thesourcecad.com/autocad-bad-practices/ Чего-то очень хочется разобрать ее "по косточкам", с чем-то согласиться, с чем-то поспорить.

Даю вольный перевод основных тезисов (кому интересно - добро пожаловать в первоисточник, можете посмотреть подробнее) и свою реакцию на них

  1. Помещение объектов на слой Defpoints. Не спорю, служебные слои в общем-то не для подобных вещей. (отключение слоя "0" приводит к блокировке объектов на Defpoints, при выполнении проверки файла (_.audit) объекты, лежащие на этом слое, могут быть распознаны как ошибочные и тогда будут перемещены на слой $AUDIT_BAD_LAYER; вроде бы еще что-то было).
  2. Объектам не назначаются настройки "ПоСлою". В некоторых (подчеркиваю - в некоторых!) случаях назначение цвета / типа линии / веса линии ПоСлою мало того, что невыгодно, так еще и вредно. Так что "нехорошесть" по вопросом.
  3. Помещение всех объектов на слой "0". Также под вопросом, особенно если создаваемый файл в дальнейшем будет использоваться как блок. Или как подложка, а используемая версия AutoCAD ниже 2016.
  4. Неиспользование стандартов именования слоев. Для Штатов, наверное, действительно - Bad Practice. Для России - не факт. Особенно учитывая, в каком диапазоне задач может использоваться AutoCAD. В каждой избушке свои погремушки. Хотя, конечно, внутри одной конторы какой-то стандарт иметь надо. И не только иметь, но и сделать так, чтобы ни пользователи, ни стандарт никого и никогда сами бы не отымели. То есть поддержка. Отдельная песня, поскольку далеко не каждая фирма может себе позволить содержать САПРовода. Я бе переформулировал: не "неиспользование", а "полное отсутствие". В таком варианте я согласный.
  5. Помещение объектов на ошибочные (не те) слои. Прямая отсылка к предыдущему пункту. Если стандарт имен слоев содержит два-три слоя, то ошибиться очень сложно (хотя и можно). При стандарте слоев с общим списком слоев в несколько сотен проблема уходит со стороны пользователя на сторону САПРовода. Этот пункт не вина пользователя, а его беда. И решать эту проблему должен точно не пользователь. Практика, конечно, не фонтан - при условии, что ясно, какие слои для каких объектов "правильные".
  6. Неназначение единиц измерения чертежа. При совместной работе множества отделов - да, может стать бедой. Но, как правило, подобное решается опять же САПРоводами и  созданием / назначением соответствующих шаблонов. То есть - "не вина, а беда".
  7. Неиспользование аннотативности. ИМХО: не есть плохо. Аннотативность нужна далеко не всем и далеко не всегда. Особенно учитывая, как себя могут вести аннотативные выноски, аннотативные блоки с аннотативными же атрибутами и т.п. В неумелых руках аннотативность принесет больше вреда, чем пользы. Не согласен.
  8. Отсутствие блокирования ВЭ в пространстве листа. Почти соглашусь. Ладно, полностью соглашусь - поскольку у меня пользователи обычно в листах ВЭ блокируют. А заодно в них же меняют состояние и настройки слоев.
  9. Блоки создаются не на слое "0". Судя по всему, автор хотел сказать, что "примитивы описания блока не лежат на слое 0". Ну, во-первых, одного лишь помещения объекта на слой "0" для обеспечения гибкости блока недостаточно. Во-вторых, опять же, подобное нужно не всем и не всегда: например, надо быстро притащить в новый чертеж сотню-другую слоев. Причем делается это примерно два раза в день. Как это проще всего сделать? Да элементарно: создаем новый файл, в котором прописываем эти слои, на каждый слой помещаем отрезок либо точку - и импортируем файл как блок. Так что огульно называть подобное "плохой практикой" я бы не стал.
  10. Внешние ссылки не помещаются на отдельный слой. В принципе, согласен, но... Шо, все ссылки на один слой? Не, я понимаю, в ACAD2016 появились очень интересные возможности по представлению ссылок, но рекомендация "все ссылки на один слой", ИМХО, способна навредить больше, чем принести пользы. Я бы сказал, что "Внешние ссылки помещайте на соответствующие слои. И слои эти не должны быть 0 или Defpoints".
  11. Неиспользование команды _.etransmit (формкомплект). Согласен на 200%
  12. Помещение объектов внутри внешней ссылки на слой "0". Спорное утверждение, спорное. Может оказаться очень востребованным в некоторых случаях. Мне, по крайней мере, пару раз пригодилось подобное.
  13. Использование полных команд вместо алиасов (сокращенных команд). Тююю, робяты, сядьте-ка со своего английского AutoCAD, например, за немецкий. Или французский. Или русский. С полностью переделанным интерфейсом (и плевать на автозавершение, нету его - порадуйтесь жизни в AutoCAD2009). И нарисуйте-ка, к примеру, 5 отрезков, пересекающую их полилинию с дуговым сегментов и выполните обрезку по контуру. А я посмеюсь. ИМХО - подобная практика говорит только о том, что человек многое знает и понимает, как оно работает. Так что это - не есть плохо.
  14. Копирование через буфер обмена из других версий AutoCAD, или файлов dwg "неправоверных", т.е. созданных не Autodesk. Причины, которые в статье обозначаются, с моей точки зрения, выглядят как-то по детски. Реальные причины немного другие, я на autolisp.ru про буфер обмена высказывался, повторяться не хочу. Но согласен.
  15. Неиспользование ассоциативной штриховки. Воу-воу, полегше! Создай-ка ассоциативную штриховку, в контур которой входит хотя бы часть внешней ссылки. Сохрани файл и попробуй его снова открыть. Радуйся тормозам и вылетам. Или еще вариант - создай ассоциативную штриховку с базовой точкой где-нибудь в районе Альфа-Центавра, и попробуй с нею поиграться. Особенно это будет касаться сложных штриховок, типа бутового камня. Так что - мимо.
  16. Неиспользование ассоциативного массива. Извините, но тут во мне начинает возмущаться программист. Я примерно понимаю, как организовываются ассоциативные массивы, динамические блоки, параметрические зависимости и как хранится история создания / редактирования твердых тел. Неоправданное применение таких новшеств может убить файл.
  17. Неиспользование команд OVERKILL и PURGE. Ага, только в насыщенных чертежах OVERKILL способен все порушить, а одного лишь PURGE недостаточно. Хотя, что я говорю - смотрим на форуме dwg.ru тему "Помогите уменьшить размер файла *.dwg", там все описано. Совет от автора хорош, но неполон. Почти в топку.
  18. Переназначение текста для размеров или неточно проставленные размеры. Наверное, автору никогда не приходилось на листе формата А3 помещать чертеж 6-метрового бруса. При этом показывается 3-4 части этого бруса, каждая в масштабе, к примеру, 1:10. А расстояния должны быть указаны реальные, а не те, что AutoCAD намерил. Да, кстати, помещать размеры по условиям задачи в пространство модели низя! Так что совет непродуман. Почти в топку.
  19. Неточная геометрия. Ну, тут спорить не стану - неиспользование привязок, как правило, способно довести САПРовца до нервного тика и желания убивать.
  20. Использование всех возможных привязок сразу и одновременно. А как насчет врвменного переназначения привязки? А как насчет того, что профилей одной версии AutoCAD может быть сколько угодно, и для каждого профиля (точнее, закрываемых им задач) надо использовать свой набор привязок? А OSMODE хранится одна на все! Так что совет использовать "свой собственный личный набор привязок" отправляется... Правильно, в топку!

Итого, из 20 советов:

Согласен полностью - пп.1, 8, 11, 14, 19. 25%

Согласен частично - пп.2, 3, 4, 5, 9, 10, 12, 17. 40%

Не согласен - пп.7, 13, 15, 16, 18, 20. 30%

В том числе:

Должно решаться не пользователями - пп.5, 6. 10%

Требует уточнения формулировки - пп.4, 10, 18. 15%