Ответ: Написал 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)