Ответ: Написал c# враппер
 

Учитывая что нету никаких локальных контейнеров с индексацией по указателям на сущности, то менеджера сущностей соответственно нету.
К чему это ведёт:
Surface surf1 = mesh.GetSurface(1);
Surface surf2 = mesh.GetSurface(1);
В результате surf1 не будет равна surf2, это будут отдельные два объекта, невзирая на то что в памяти есть уже этот самый сюрфейс, и указатель на него (handle) у них одинаковый.
Это не экономно к памяти, и приведёт к большим затратам, порой к катастрофическим если класс объекта будет не маленьким. Постоянно вызывать конструктор и т.п.

Классы начинаются с "Т" - это что, blitzmax style? Сейчас так никто не пишет.
Также использование "_" для приватных переменных объекта, в C# давно никто не юзает тоже. Т.к. почти везде рекомендуется ВСЕ переменные держать в виде приватных мемберов, и писать для доступа к ним аксессоры. Таким образом использование "_" становится не нужным, иначе все переменные будут его иметь, и какой тогда в этом смысл?
Ещё по стилю, куча переменных с заглавных букв - это уже вообще ни в какие ворота.. Используй camelCase, без _.

Относительно многих файлов, их нужно почистить. Например TBlend.cs имеет uses'ы, которые там вообще не нужны.

Наименование Namespace'а, вообще ни как не соответствует тому что это такое. Он должен говорить что в этом именном пространстве, а не какой-то "Х???".

Куча объектов создаваемых в TEntity, когда не факт что хоть один будет юзаться.

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

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

В общем, как начало - неплохо, но для продолжения нужно много чего изменить и привезти в порядок.
Если ты так хочешь иметь эти все объекты (типо TJoints) в энтитях, то хотя бы инициализируй их в аксессорах к этим фиелдам, чтобы не было лишних созданий.

В общем, много над чем есть работать. Где тех доки по тому что это и как это вообще работает?
Снова никакой документации вообще.

Ответ: Написал c# враппер
 

Ну и где тут не читабельный или плохо читабельный код?

Ответ: Написал c# враппер
 

раз уж пошла такая пьянка
тоже использую подчёркивания для приватных филдов. неприватные филды стараюсь не делать вообще - мешает реюзабельности.
В команде изначально был принят стандарт по именованию переменных. что избавляет от лишней траты времени на пролистывания истинга чтобы узнать кому принадлежит переменная. также приняты "Is..." и "Has..." как узкатаели на булевский функции и члены.
Не понимаю как может упасть читабельность от "_". это наоборот повзоляет избегать конфликтов зон видимостей, так как можно принимать одноимённые имена переменных в качестве аргументов функций "_position" -"position" - что делает код читабельней. использование "this" считаю излишним и признаком плохого проектирования.

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

По мне так удобнее, и встретил кучу Open Source проектов, использующих очень близкий к этому стилю:



А это вообще ни в какие ворота. Бьёт по производительности ужасно. Речь идёт о C#. И тут лучше использовать Acessor'ы, для обращения к данным класса. Это реюзабельней, и более масштабируемо, т.к. можно заменить лишь тело аксессора, и везде будут применены изменения. В случае с переменными, так не пройдёт. Плюс внедрение например эвентов при изменении переменной и т.п. - это снова, чтобы это сделать, если использовал прямой доступ, придётся везде менять, во всех проектах где юзается это. А если юзался аксессор, то лишь в нём добавиться одна / две строки кода, и всё. Нигде менять не нужно.
Читаю не внимательно.

Это хорошо имхо, только это нужно делать не для переменных (Is.. и Has..) а для аксессоров снова.

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

Читабельность и конфликты видимостей переменных - две разные темы.
Использование "this." позволяет чётко даже не знающему класса понять что обращение идёт к мемберу класса. Некоторые программисты использовали _ в начале переменных совсем иначе, и это не "становленное" правило языком. Поэтому если полагаться на то что ВСЕ переменные с "_" вначале - мемберы экземпляра, то тут можно конкретно наломаться, когда будешь бегать по чужому коду, кто например помечает также "_" локальные переменные.

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

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

Ответ: Написал c# враппер
 

Читай мой комент сначала и вдумчиво, ага.

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

Это вообзе бред какойто. также вообще нельзя ниначто полагаться в чужом коде по твоей логике. Поэтому я и говорю про чёткое определение.

Это не нормально - это плохое представление о классе и проектировании в целом. это отже самое что называть два класса одинаково в разных неймспейсах.

Ответ: Написал c# враппер
 

Слажал - прочёл вверх дном.


Также как если у тебя в одном месте _property а в другом property, нужно знать, это локальная переменная, или это мембер?
Венгерская нотация - тоже чёткие правила, и минусов там лишь прибавилось.
Все правила что есть выше самого языка по уровню, они будут всегда везде разные, каждая команда пишет код как хочет. Но что они сделать не могут - это идти против правил диктуемых языком: тот же "this.".

Нельзя конечно! Пока сам точно не будешь уверен что там что-то работает, то нельзя полагаться. Иначе если там ошибка, о которой ты не знаешь, и будет баг, то искать ты его замахаешься.
Все пишут код как им угодно. Нету мировых стандартов вообще. Каждый нарабатывает свой стиль. Но есть некоторые моменты, которые лучше не делать по тем или иным причинам. Проблегись по реально крупным Open Source проектам, студий которые имеют хороший опыт в разработке на .Net. Большинство отказывается от "_" и это разумно.

Не то же самое вообще.
Хорошо, вот тебе пример:
Если наименовать параметр как "newPosition", то это будет сбивать с толку когда будешь набирать код, смотришь на параметры (ожидаешь чтобы они говорили сами за себя), а тут у тебя просят новую позицию, это что нада новый экземпляр vec3 делать? Раз просят новую, или там будет автоматически клонироваться позиция?
И таких примеров много, когда в метод передаются параметры с наименованием совпадающим с их мемберами. И никаких ограничений по именам параметров и не должно быть как таковой, этого ведь другой разработчик не знает, и не должен об этом вообще париться.

Ответ: Написал c# враппер
 

Не буду все комментировать, так как это видимо бессмысленно. Вот четко и ясно:

Ответ: Написал c# враппер
 

Уху, я упоротый.

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

Ответ: Написал c# враппер
 

Приватные переменные не наследуются ;)

Ответ: Написал c# враппер
 

Это дураку понятно (хотя и есть рефлекции). Не обязательно это приватная переменная, она может быть protected.

Ответ: Использование "_" или "this." для локальным переменных экземпляра класса.
 

разговора про protected не было ;)

Ответ: Использование "_" или "this." для локальным переменных экземпляра класса.
 

Разговор идёт о использовании переменных, а учитывая сложность классов, они могут юзать очень много всего разного.

Ответ: Использование "_" или "this." для локальным переменных экземпляра класса.
 

Спор был о
И тему кстати назвали правильно ;)

Ответ: Использование "_" или "this." для локальным переменных экземпляра класса.
 

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

Получается "_" лишь указывает на их приватность, а не на факт их локальности видимости относительно экземпляра класса?

А публичные филды делать - плохой тон. Правильно - свойства. А для свойств правила - CamelCase

Кстати вот:
http://en.wikipedia.org/wiki/Naming_convention_(programming)

Ответ: Использование "_" или "this." для локальным переменных экземпляра класса.
 

Уху, и при этом полная вырезка относящаяся к очень коммерчески популярному языку Java - который является "близнецом" C#.
Насчёт того что для переменныз юзать lowerCamelCase (или camelBack), а для аксессоров использовать CamelCase - это полностью согласен и за. Тем более лично против использования "_" в наименованиях перменных или классов вообще. У меня он вообще не встречается, и код имхо читабельнее. В крупных OpenSource проектах тоже частенько можно найти где их вообще нету и не используют.

Ответ: Использование "_" или "this." для локальным переменных экземпляра класса.
 

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

Я скажу по собственному опыту - использование знака подчеркивания делает более читабельным код (для меня точно) и чаще ускоряет кодинг.

Ответ: Использование "_" или "this." для локальным переменных экземпляра класса.
 

Ну тут да, я загнул. Используют, но явная тендеция - уходить от этой привычки очень распространена.

Читабельность не лучше чем с использованием "_", а учитывая разницу стилей, то если рассматривать разработчика который не знаком с подобным стилем, потребуется ознакомление и привычка. Когда при использовании this. - этого не требуется, т.к. это часть спецификации языка и common sense.
Насчёт ускорения кодинга, ну тут если только в колличестве символов. Обращение к локальным переменным также шустро через this. как и через _.
Тем более, когда обращаешься к мемберам класса (переменным, методам, аксессорам и т.п.), то в голове всегда будет сразу "this." и без разделений так даже проще: хочешь обратиться к личной сущности экземпляра, автоматом набираешь "this.", и получаешь удобный список всех личных сущностей.
При этом многие шустрые разрабы (отличный пример в онлайн туториалах, где народ надрочен и кодит достаточно шустро), всё равно будешь набирать почти полное имя переменной, или хотя бы ту часть, начиная с которой эта переменная останеться одна или будет уже выделена в автодополнении. Редко кто юзает стрелки и темболее мышку чтобы искать нужную переменную, только в случае если ты не знаешь их. Тогда да, _ - сразу отфильтрует остальное от локальных, приватных перемен. Но это в случае если нигде глобально с "_" ничего не начиналось, иначе пойдёт полная каша.

Дело лично каждого. Я лишь заметил такую тенденцию что всё меньше и меньше юзают "_". Да и большинство кода, примеров и т.п. из msdn также меньше и меньше юзает "_", я уже почти вообще не встречаю этого.

Ответ: Использование "_" или "this." для локальным переменных экземпляра класса.
 

this.fieldName это ГАРАНТИЯ от компилятора.
_fieldName это соглашение, которое форсится людьми и ими же нарушается.

поэтому я ненавижу всякие ПРЕФИКСЫ.
одинарное подчеркивание, некоторые доходят до двойного и тройного...
так же всякие m_memberName вызывают неприятие.

хороший код опирается на компилятор, плохой - на соглашения между людьми.

Ответ: Использование "_" или "this." для локальным переменных экземпляра класса.
 

Двойные и тройные подчеркивания это перебор, префиксы с m_ тоже отвратительны.

Ответ: Использование "_" или "this." для локальным переменных экземпляра класса.
 

Я считаю, что использовать префикс "_" нужно в тех ЯП где нет Private (например BlitzMax) в остальных можно обойтись и без этого. Префикс "_" сводит на нет автокомплит в IDE. Вернее он замедляет процесс нахождения нужного элемента для подстановки.

Почему public для полей - плохой тон? Лучше что-ли писать на каждое поле GetValue/SetValue?

Ответ: Использование "_" или "this." для локальным переменных экземпляра класса.
 

Да лучше. Лучше вместо поля создать автосвойство. Такой подход в любое время позволит сделать обработку присвоения/взятия значения преобразовав автосвойство в нормальное свойство.
Открытые поля в Net Framework характерны только для структур.

Ответ: Использование "_" или "this." для локальным переменных экземпляра класса.
 

правда это не шарп.
использую постфикс _ для приватных элементов класса. с одной стороны это позволяет выносить в интерфейс нормальные имена методов. т.е. например instance_ и instance(). с другой имеется и осмысленное имя переменной и интеллисенс не замедляется. на работе принят стандарт с m_someName;

Ответ: Использование "_" или "this." для локальным переменных экземпляра класса.
 

Как уже писал:
Бьёт по производительности. И тут лучше использовать Acessor'ы, для обращения к данным класса. Это реюзабельней, и более масштабируемо, т.к. можно заменить лишь тело аксессора, и везде будут применены изменения. В случае с переменными, так не пройдёт. Плюс внедрение например эвентов при изменении переменной и т.п. - это снова, чтобы это сделать, если использовал прямой доступ, придётся везде менять, во всех проектах где юзается это. А если юзался аксессор, то лишь в нём добавиться одна / две строки кода, и всё. Нигде менять не нужно. Либо менять имя переменной, и делать аксессор тем же именем как была переменная, но учитывая правила наименований сущностей - это будет грубым нарушением, что в результате ни в какие ворота.
Плюс ограничения доступа, если нужно сделать переменную модифицируемой только изнутри, а получаемой от куда угодно, или наоборот и т.п.

Ответ: Использование "_" или "this." для локальным переменных экземпляра класса.
 

обычно юзаю префикс для мемберов класса mFieldName !! и все ок !! :)

Ответ: Использование "_" или "this." для локальным переменных экземпляра класса.
 

MoKa, я с тобой. Тоже за нормальное именование.
Приватные от не приватных разделяю написанием первого слова в названии.

doSmth() — приватная функция
DoSmth() — не приватная

Ответ: Использование "_" или "this." для локальным переменных экземпляра класса.
 

Зачем различать приватные и публичные функции?

Ответ: Использование "_" или "this." для локальным переменных экземпляра класса.
 

Мне это кажется удобным.