Резюме для программиста
В WPF тоже нет выпадающего списка объектовА это тогда что? С решарпером и без него
Не это. Наведите на байндинг. Если контекст данных установлен ранее, то по идее движок дизайнера XAML должен знать, что за тип будет байндиться, и выдавать подсказки по публичным полям этого объекта при установке байндинга. А он не выдаёт.
Сишарп только относительно недавно (с 6 версии, с 2015 года) избавился от необходимости передавать названия элементов языка строками вручную. А атрибут CallerMemberName позволил избавиться от передачи вручную строкового имени изменяемого свойства при реализации INotifyPropertyChanged. В идеале ничего строкового вообще не должно передаваться вручную - чревато ошибками и нужно помнить или постоянно подсматривать названия. Один этим атрибутом столько лишней мелочной рутинной работы убрали, которая просто забивала код ненужной фигнёй, а программиста постоянно отвлекала. Но почему-то это всё появилось спустя более 10 лет после выхода дотнета.
то ну их нафиг, голову себе забивать.Это только на вашем острове так можно.
Вы именуете переменные-члены класса с подчёркивания?
Помню, для специальной реализации обработки событий в борладовском варианте C++ были так называемые fastcall функции, которые начинались с двойного подчёркивания.
Я не сталкивался с Юнити, но :)
В Юнити в скриптах нет свойств, поэтому используются данные-члены класса непосредственно.
Т.е. в Юнити нет пропертей?
И кроме того, чтобы эти данные-члены были доступны в самом Юнити при настройке объектов, их нужно делать открытыми. Понимаете? - Открытые данные-члены класса.
В С++ тоже нет пропертей, однако это не мешает писать код в соответствии со всеми правилами ООП. Более того, проперти - это "синтаксический сахар", не более того :)
Это смертельный грех для ООП.
Смертельный грех - нарушать инкапсуляцию, т.е. раскрывать устройство класса.
И меня всегда это тяготило - во-первых, кроме этой конвенции нет больше никакого контроля - ни встроенного в язык, ни в IDE - что начинающиеся с подчёркивания имена - члены именно этого класса.
Это просто договоренность. При этом договоренность внутри команды. Проперти (публичные переменные) пишутся с заглавной буквы, приватные переменные - с подчеркивания или с "m_", локальные - с прописной буквы. При этом кто-то еще и венгерскую нотацию использует.
Не это. Наведите на байндинг.
Не играет рояли на куда наводить везде показывает, решарпер конечно лучше
Не играет рояли на куда наводить везде показывает, решарпер конечно лучше
Это у вас список свойств и метедов объекта, который вы привязываете?
В Юнити в скриптах нет свойств, поэтому используются данные-члены класса непосредственно.Т.е. в Юнити нет пропертей?
Я поспешил и неправильно сказал. Там свойства есть, но почему-то они нарушают правило именования CamelCase и пишут их с большой буквы.
Кроме того, чтобы в редакторе Юнити эти свойства у объектов появились, их надо делать открытыми полями
"In C#, you must declare a variable as public to see it in the Inspector." Unity - Manual: Variables and the Inspector (unity3d.com)
Либо можно закрытыми и добавить открытых свойств над этим полем (как привыкли в обычном дотнете), но тогда поле сделать сериализуемым - например, добавить атрибут сериализации. Это потому, как я понял, что Юнити получает объекты из скрипта сишарпа через сериализацию. Многим от сишарпа в Юнити не надо сильно уж мощного ООП, поэтому между двумя следующими вариантами они выбирают тот, что короче и проще:
[SerializeField] private int foo; public int Foo { get { return foo; } set { foo = value; } }
public int foo;
А вот как в самом Юнити выглядят свойства (т.е. это их код - создателей Юнити):
public sealed class GameObject : Object { public GameObject(); public Transform transform { get; } public int layer { get; set; }
Типичный способ правильно писать игры на Юнити, как я понял - писать всю игровую логику в отдельной сборке на шарпе по всем правилам шарпа, а скрипты Юнити использовать как своего рода вью модель (если мы о MVVM), в которую передавать объекты из сборки с логикой игры (т.е. модель). Новички или те, кто создают простые примеры, пишут всё в файлах скриптов. Это как писать логику десктопного приложения в слое с обработчиками событий интерфейса.
список свойств и методов объекта, который вы привязываете?
Да, список возможных команд в данном случае
Там свойства есть, но почему-то они нарушают правило именования CamelCase
По идее там Паскаль-кейс
https://docs.microsoft.com/en-us/dotnet/csharp/fundamental...
Там свойства есть, но почему-то они нарушают правило именования CamelCaseПо идее там Паскаль-кейс
Вобщем, свойства там с маленькой буквы, данные и методы должны быть открытыми, чтобы быть видны в самом Юнити.
Если придерживаться шаблона MVVM или в принципе разделения на слои, то логично. По разным причинам у слоя с графикой (вью) могут быть свои требования к оформлению кода и как и какие данные должны быть объявлены. Поэтому пишется своя вью модель для каждого типа представлений - для адаптации данных модели к представлению. Для Юнити вот такие требования, как выше, для WPF - свои, типа реализации INotifyPropertyChanged, команд и т.п.
Можно написать приложение многослойное, где в одной сборке будет общая логика и несколько сборок - под разные типы клиентской графики (WPF, веб, Юнити). В моём проекте были такие слои как DB (MS SQL Server), ORM (C# Entity Framework Code First), Model (C#), DTO (C#, JSON), View Model (C#), View (WPF, HTML, JS, CSS), ну и слой для общения с железками Лабвью, где была бинарная сериализация по кастомному протоколу.
Тут в некоторых вакансиях встречаются такие требования как Visual Studio 2015. Я не знаком подробно с лицензионным соглашением по Студии (последнее время только с коммьюнити эдишн работал, а до этого была купленная предприятием версия) - там лицензии покупаются на одну конкретную версию, и любая более новая - только через дополнительные траты? Просто сидеть на версии 2015 сейчас - сплошная боль. Да и не поразрабатываешь нормально на ней - фреймворк не выше 4.6.х, версия языка 6, 10 винды нет, коре всякие - только первая версия. Явно проект какой-то доисторический.
Не, отказаться от возврата кортежей из функций я уже не готов. ))
Просто сидеть на версии 2015 сейчас - сплошная боль
Конечно, но это исходит от требования - WPF
Сейчас все на Ангуляре помешаны.
Тут в некоторых вакансиях встречаются такие требования как Visual Studio 2015.
Эти требования можно пропускать :)
там лицензии покупаются на одну конкретную версию, и любая более новая - только через дополнительные траты?
Дело не в тратах на софт (тем более, что многие просто покупают подписку), дело в тратах на переход на новый софт. Для того, чтобы сменить среду разработки должны быть очень веские основания. Т.е. новая среда должна что-то добавить. У нас в проекте используется VS2015 и переходить на что-то более новое просто нет смысла. На прошлом проекте мы перешли на VS2015 (не помню уже с какой) ради TestCoverage.
Просто сидеть на версии 2015 сейчас - сплошная боль.
Ошибаешься. Вообще никакой разницы, что 2015, что 2019 :D
Да и не поразрабатываешь нормально на ней - фреймворк не выше 4.6.х
Фреймворк можно доустановить. У меня доустановлен 4.8 и все работает ;)
версия языка 6
Я особенно не слежу, но ограничений что-то не помню :)
10 винды нет
Поясни. Сейчас вообще никакой винды, кроме 10 нет :)
коре всякие - только первая версия.
Доустанавливается, как и фреймворк.
Явно проект какой-то доисторический.
Как и подавляющее количество всех проектов на рынке :D
Да и не поразрабатываешь нормально на ней - фреймворк не выше 4.6.хФреймворк можно доустановить. У меня доустановлен 4.8 и все работает ;)
версия языка 6Я особенно не слежу, но ограничений что-то не помню :)
10 винды нетПоясни. Сейчас вообще никакой винды, кроме 10 нет :)
Там зависимости версии Студии и фреймворка. Разве что от версии Виндовс не так сильно зависит (самое последнее ставится на Win 7 SP1).
.net - What are the correct version numbers for C#? - Stack Overflow
Не знаю. Магия какая-то. А оно точно создаётся - проекты на 4.8 под 2015? Фреймворк, допустим, в системе, а Студию попросит обновить, может быть? Не просто же так табличку совместимости составили.
Я знаю, что можно на новой Студии старые фреймворки использовать. А чтобы наоборот - смысл тогда Студии покупать-обновлять каждые 2-3 года? Народ бы сидел по 5-10 лет.
Таблица совместимости студий и версий фреймворка
Ну может быть "no add-on" означает что-то вроде "из коробки"?
Я у себя клачаю на "Install other frameworks..." и меня перекидывает сюда. Скачиваю фреймворк (developer pack) и вуаля.
смысл тогда Студии покупать-обновлять каждые 2-3 года? Народ бы сидел по 5-10 лет.
Так никто каждые 2-3 года и не обновляет :) И никто не переходит на новый фреймворк просто из-за того, что вышла новая версия :) Для перехода всегда есть очень серьезные причины. И выход новой версии какого-либо продукта не является серьезной причиной :D
Вобщем, некоторые эйчары упорно требуют Arbeitszeugnis, даже если я им пишу, что опыта в Германии нет. Короче, как я понял, им нужна любая бумага от прошлого работодателя - просто эйчарам, похоже, премии дают, если они заполняют свои базы резюме наиболее полно (чтобы всё по пунктам было, и пофиг, что часть из них нелогична).
Таким отсылаю перевод своей Arbeitsbuch, т.к. это по сути единственная бумага от прежнего работодателя в России, а рекомендательные письма в России не принято давать-писать.
я им пишу, что опыта в Германии нет
Это не вписывается в их алгоритм работы. Нужно писать, типа, что согласно законам страны предыдущего пребывания для Arbeitszeugnis имеется только трудовая книжка.