Резюме для программиста
В 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 винды нет, коре всякие - только первая версия. Явно проект какой-то доисторический.
Не, отказаться от возврата кортежей из функций я уже не готов. ))
Тут в некоторых вакансиях встречаются такие требования как 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, т.к. это по сути единственная бумага от прежнего работодателя в России, а рекомендательные письма в России не принято давать-писать.