Извините, ничего не найдено.

Не расстраивайся! Лучше выпей чайку!
Регистрация
Справка
Календарь

Вернуться   forum.boolean.name > Программирование игр для компьютеров > С#

С# Средство разработки на платформе .Net

Ответ
 
Опции темы
Старый 14.11.2011, 15:32   #1
moka
.
 
Регистрация: 05.08.2006
Сообщений: 10,429
Написано 3,454 полезных сообщений
(для 6,863 пользователей)
Ответ: Написал 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) в энтитях, то хотя бы инициализируй их в аксессорах к этим фиелдам, чтобы не было лишних созданий.

В общем, много над чем есть работать. Где тех доки по тому что это и как это вообще работает?
Снова никакой документации вообще.
(Offline)
 
Ответить с цитированием
Старый 14.11.2011, 17:22   #2
pax
Unity/C# кодер
 
Аватар для pax
 
Регистрация: 03.10.2005
Адрес: Россия, Рязань
Сообщений: 7,568
Написано 3,006 полезных сообщений
(для 5,323 пользователей)
Ответ: Написал c# враппер

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

Последний раз редактировалось moka, 14.11.2011 в 21:09.
(Offline)
 
Ответить с цитированием
Эти 3 пользователя(ей) сказали Спасибо pax за это полезное сообщение:
.Squid (14.11.2011), h1dd3n (14.11.2011), Lestar (15.11.2011)
Старый 14.11.2011, 18:40   #3
Dream
быдло
 
Регистрация: 05.08.2007
Сообщений: 1,435
Написано 614 полезных сообщений
(для 1,489 пользователей)
Ответ: Написал c# враппер

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

Последний раз редактировалось moka, 14.11.2011 в 21:09.
(Offline)
 
Ответить с цитированием
Старый 14.11.2011, 18:58   #4
moka
.
 
Регистрация: 05.08.2006
Сообщений: 10,429
Написано 3,454 полезных сообщений
(для 6,863 пользователей)
Когда вбиваешь "_" и выдаёт приватные переменные - это ок. Но что если ты используешь и не приватные в классе, получается чтобы обратиться к ним, нужно знать локальна она или нет, чтобы начинать с "_" или без.

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



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

Сообщение от Dream Посмотреть сообщение
В команде изначально был принят стандарт по именованию переменных. что избавляет от лишней траты времени на пролистывания истинга чтобы узнать кому принадлежит переменная. также приняты "Is..." и "Has..." как узкатаели на булевский функции и члены.
Это хорошо имхо, только это нужно делать не для переменных (Is.. и Has..) а для аксессоров снова.

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

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

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

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

Последний раз редактировалось moka, 14.11.2011 в 21:10.
(Offline)
 
Ответить с цитированием
Старый 14.11.2011, 19:14   #5
Dream
быдло
 
Регистрация: 05.08.2007
Сообщений: 1,435
Написано 614 полезных сообщений
(для 1,489 пользователей)
Ответ: Написал c# враппер

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


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

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

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

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

Последний раз редактировалось moka, 14.11.2011 в 21:10.
(Offline)
 
Ответить с цитированием
Старый 14.11.2011, 20:20   #6
moka
.
 
Регистрация: 05.08.2006
Сообщений: 10,429
Написано 3,454 полезных сообщений
(для 6,863 пользователей)
Ответ: Написал c# враппер

Сообщение от Dream Посмотреть сообщение
Читай мой комент сначала и вдумчиво, ага.
Слажал - прочёл вверх дном.


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

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

Сообщение от Dream Посмотреть сообщение
Это не нормально - это плохое представление о классе и проектировании в целом. это отже самое что называть два класса одинаково в разных неймспейсах.
Не то же самое вообще.
Хорошо, вот тебе пример:
public void SetPosition(vec3 position) {
   this.position = position;
}
Если наименовать параметр как "newPosition", то это будет сбивать с толку когда будешь набирать код, смотришь на параметры (ожидаешь чтобы они говорили сами за себя), а тут у тебя просят новую позицию, это что нада новый экземпляр vec3 делать? Раз просят новую, или там будет автоматически клонироваться позиция?
И таких примеров много, когда в метод передаются параметры с наименованием совпадающим с их мемберами. И никаких ограничений по именам параметров и не должно быть как таковой, этого ведь другой разработчик не знает, и не должен об этом вообще париться.
(Offline)
 
Ответить с цитированием
Старый 14.11.2011, 20:28   #7
pax
Unity/C# кодер
 
Аватар для pax
 
Регистрация: 03.10.2005
Адрес: Россия, Рязань
Сообщений: 7,568
Написано 3,006 полезных сообщений
(для 5,323 пользователей)
Ответ: Написал c# враппер

Сообщение от MoKa Посмотреть сообщение
Хорошо, вот тебе пример:
public void SetPosition(vec3 position) {
   this.position = position;
}
Если наименовать параметр как "newPosition", то это будет сбивать с толку когда будешь набирать код, смотришь на параметры (ожидаешь чтобы они говорили сами за себя), а тут у тебя просят новую позицию, это что нада новый экземпляр vec3 делать? Раз просят новую, или там будет автоматически клонироваться позиция?
И таких примеров много, когда в метод передаются параметры с наименованием совпадающим с их мемберами. И никаких ограничений по именам параметров и не должно быть как таковой, этого ведь другой разработчик не знает, и не должен об этом вообще париться.
Не буду все комментировать, так как это видимо бессмысленно. Вот четко и ясно:
public void SetPosition(vec3 position) {
   
_position position;

__________________
Blitz3d to Unity Wiki
(Offline)
 
Ответить с цитированием
Сообщение было полезно следующим пользователям:
Dream (14.11.2011)
Старый 14.11.2011, 20:36   #8
moka
.
 
Регистрация: 05.08.2006
Сообщений: 10,429
Написано 3,454 полезных сообщений
(для 6,863 пользователей)
Ответ: Написал c# враппер

Сообщение от pax Посмотреть сообщение
Не буду все комментировать, так как это видимо бессмысленно. Вот четко и ясно:
public void SetPosition(vec3 position) {
   
_position position;

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

"_" - не явно указывает тем кто со стилем не знаком. Им придётся смотреть где она объявлена. Может это константа, или статическая переменная класса, а может вообще отцовского класса какая переменная.
Если this. - тот тут любой поймёт, т.к. это уже определено языком, от куда она идёт, и то что это мембер экземпляра, а никакая например не константа класса.
(Offline)
 
Ответить с цитированием
Старый 14.11.2011, 20:39   #9
pax
Unity/C# кодер
 
Аватар для pax
 
Регистрация: 03.10.2005
Адрес: Россия, Рязань
Сообщений: 7,568
Написано 3,006 полезных сообщений
(для 5,323 пользователей)
Ответ: Написал c# враппер

Сообщение от MoKa Посмотреть сообщение
Им придётся смотреть где она объявлена. Может это константа, или статическая переменная класса, а может вообще отцовского класса какая переменная.
Приватные переменные не наследуются
__________________
Blitz3d to Unity Wiki
(Offline)
 
Ответить с цитированием
Сообщение было полезно следующим пользователям:
Dream (14.11.2011)
Старый 14.11.2011, 21:11   #10
moka
.
 
Регистрация: 05.08.2006
Сообщений: 10,429
Написано 3,454 полезных сообщений
(для 6,863 пользователей)
Ответ: Написал c# враппер

Сообщение от pax Посмотреть сообщение
Приватные переменные не наследуются
Это дураку понятно (хотя и есть рефлекции). Не обязательно это приватная переменная, она может быть protected.
(Offline)
 
Ответить с цитированием
Старый 14.11.2011, 21:15   #11
pax
Unity/C# кодер
 
Аватар для pax
 
Регистрация: 03.10.2005
Адрес: Россия, Рязань
Сообщений: 7,568
Написано 3,006 полезных сообщений
(для 5,323 пользователей)
Ответ: Использование "_" или "this." для локальным переменных экземпляра класса.

разговора про protected не было
__________________
Blitz3d to Unity Wiki
(Offline)
 
Ответить с цитированием
Старый 14.11.2011, 21:53   #12
moka
.
 
Регистрация: 05.08.2006
Сообщений: 10,429
Написано 3,454 полезных сообщений
(для 6,863 пользователей)
Ответ: Использование "_" или "this." для локальным переменных экземпляра класса.

Сообщение от pax Посмотреть сообщение
разговора про protected не было
Разговор идёт о использовании переменных, а учитывая сложность классов, они могут юзать очень много всего разного.
(Offline)
 
Ответить с цитированием
Старый 14.11.2011, 21:56   #13
pax
Unity/C# кодер
 
Аватар для pax
 
Регистрация: 03.10.2005
Адрес: Россия, Рязань
Сообщений: 7,568
Написано 3,006 полезных сообщений
(для 5,323 пользователей)
Ответ: Использование "_" или "this." для локальным переменных экземпляра класса.

Сообщение от MoKa Посмотреть сообщение
Разговор идёт о использовании переменных, а учитывая сложность классов, они могут юзать очень много всего разного.
Спор был о
Сообщение от MoKa Посмотреть сообщение
Также использование "_" для приватных переменных объекта, в C# давно никто не юзает тоже.
И тему кстати назвали правильно
__________________
Blitz3d to Unity Wiki
(Offline)
 
Ответить с цитированием
Старый 14.11.2011, 21:59   #14
moka
.
 
Регистрация: 05.08.2006
Сообщений: 10,429
Написано 3,454 полезных сообщений
(для 6,863 пользователей)
Ответ: Использование "_" или "this." для локальным переменных экземпляра класса.

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

Получается "_" лишь указывает на их приватность, а не на факт их локальности видимости относительно экземпляра класса?
(Offline)
 
Ответить с цитированием
Старый 14.11.2011, 22:02   #15
pax
Unity/C# кодер
 
Аватар для pax
 
Регистрация: 03.10.2005
Адрес: Россия, Рязань
Сообщений: 7,568
Написано 3,006 полезных сообщений
(для 5,323 пользователей)
А публичные филды делать - плохой тон. Правильно - свойства. А для свойств правила - CamelCase

Кстати вот:
Certain coding conventions state that underscores should be used to prefix all instance variables, for improved reading and program understanding.
http://en.wikipedia.org/wiki/Naming_convention_(programming)
__________________
Blitz3d to Unity Wiki
(Offline)
 
Ответить с цитированием
Ответ


Опции темы

Ваши права в разделе
Вы не можете создавать темы
Вы не можете отвечать на сообщения
Вы не можете прикреплять файлы
Вы не можете редактировать сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.


Часовой пояс GMT +4, время: 08:57.


vBulletin® Version 3.6.5.
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Перевод: zCarot
Style crйe par Allan - vBulletin-Ressources.com