Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!
Werbeanzeige
Wenn du so viel code hast, dass du das nicht erkennst, sind deine klassen eh zu gross.Was ist das für ein Code-Design, wenn man davon ausgeht, dass man einen Compiler (bzw. Editor), der Instellisense hat, benutzen muss, um einen Zeiger von einer normalen Variable zu unterscheiden, ohne dauernd in Klassendefinitionen nachzusehen?
Meiner Meinung nach sind gerade Bezeichnungen wie a für Array, r für Referenz und p für Pointer die Wichtigsten, m_ und g_ sind vor allem für Personen wichtig, die den Code später verstehen sollen und die restlichen Präfixe bringen tatsächlich nicht viel.
Es gibt viele Fälle, wo man Pointer nicht leicht von Referenzen und normalen Variablen unterscheiden kann, insbesonders dann, wenn man sehr lange Funktionen hat.
Und warum ein "a" für "array", wenn du zB für vector keine besondere notation verwendest?
Da kannst du sagen, was du willst, manche Klassen sind eben groß und abstrakt, genau wie manche Methoden eben auch, egal wie weit man sie auf andere Methoden verteilen mag (was damit die Größe der Klasse wiederum beeinflusst).
Die Aussage, dass die Klasse oder Methode dann wohl zu groß ist, die weist direkt darauf hin, dass du die Variable also doch nicht aus dem Kontext erkennst, sondern es mit einem zweiten Blick auf die Klasse/Methode nachschaust - egal wie groß oder klein die Klasse/Methode auch sein mag, du brauchst also den zweiten Blick. Das ist aber genau das, was mit z.B. "m_" oder "_" oder wasauchimmer verhindert werden soll.
Meine Frage scheint damit geklärt. Anstatt ein schönes Beispiel zu bringen, hast Du Dich nur darüber ausgelassen, was wohl an meinen Sachen falsch wäre.
Sehr schade, ich hatte auf ein konstruktives Beispiel gehofft.
C-/C++-Quelltext |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 |
void AnimatedModel::load(const char* name) { Resource::File file(name, "MODEL"); const TowerModelFileFormat::Header& header = file.get<TowerModelFileFormat::Header>(); if (header.magic != TowerModelFileFormat::magic_id) throw std::runtime_error("Invalid File Format"); size_t vertex_count = file.get<TowerModelFileFormat::size_t>(); vertices.resize(vertex_count); for (size_t i = 0; i < vertex_count; ++i) { const TowerModelFileFormat::Vertex& v = file.get<TowerModelFileFormat::Vertex>(); vertices[i].pos[0] = v.pos[0]; vertices[i].pos[1] = v.pos[1]; vertices[i].pos[2] = v.pos[2]; vertices[i].n[0] = v.n[0]; vertices[i].n[1] = v.n[1]; vertices[i].n[2] = v.n[2]; vertices[i].t[0] = v.t[0]; vertices[i].t[1] = v.t[1]; vertices[i].t[2] = v.t[2]; vertices[i].b[0] = v.b[0]; vertices[i].b[1] = v.b[1]; vertices[i].b[2] = v.b[2]; vertices[i].texcoord[0] = v.texcoord[0]; vertices[i].texcoord[1] = v.texcoord[1]; vertices[i].bone = v.bone; } size_t face_count = file.get<TowerModelFileFormat::size_t>(); size_t index_count = 3 * face_count; indices.resize(index_count); for (size_t i = 0; i < face_count; ++i) { const TowerModelFileFormat::Face& t = file.get<TowerModelFileFormat::Face>(); for (int j = 0; j < 3; ++j) indices[3 * i + j] = t.v[j]; } size_t material_count = file.get<TowerModelFileFormat::size_t>(); groups.resize(material_count); for (size_t i = 0; i < material_count; ++i) { const TowerModelFileFormat::Material& material = file.get<TowerModelFileFormat::Material>(); if (material.texture_name[0] != '\0') { std::string tex_name = material.texture_name; try { groups[i].diffuse_tex = GL::Texture2D((tex_name + ".diffuse").c_str()); groups[i].normal_map = GL::Texture2D((tex_name + ".normal").c_str()); } catch (...) { } groups[i].start_index = material.start * 3; groups[i].index_count = material.face_count * 3; } } size_t joint_count = file.get<TowerModelFileFormat::size_t>(); for (size_t i = 0; i < joint_count; ++i) { const TowerModelFileFormat::Joint& j = file.get<TowerModelFileFormat::Joint>(); SbRotation rot = SbRotation(SbVec3f(1.0f, 0.0f, 0.0f), j.rotation[0]); rot *= SbRotation(SbVec3f(0.0f, 1.0f, 0.0f), j.rotation[1]); rot *= SbRotation(SbVec3f(0.0f, 0.0f, 1.0f), j.rotation[2]); SbMatrix mat; mat.setTransform(SbVec3f(j.position[0], j.position[1], j.position[2]), rot, SbVec3f(1.0f, 1.0f, 1.0f)); joints.push_back(Joint(mat, i, j.parent == -1 ? 0 : &joints[j.parent], j.parent)); } size_t anim_count = file.get<TowerModelFileFormat::size_t>(); for (size_t i = 0; i < anim_count; ++i) { const TowerModelFileFormat::Animation& anim = file.get<TowerModelFileFormat::Animation>(); Animation::channel_vector channels(joint_count); for (size_t j = 0; j < joint_count; ++j) { channels[j] = Animation::Channel(file); } animations.insert(std::make_pair(anim.name, new Animation(*this, channels))); } for (size_t i = 0; i < vertex_count; ++i) { if (vertices[i].bone != -1) { SbVec3f pos; const SbMatrix& absolute = joints[vertices[i].bone].bind_absolute(); SbMatrix inv_absolute = absolute.inverse(); inv_absolute.multVecMatrix(vertices[i].pos, pos); vertices[i].pos = pos; } } vb = GL::VertexBuffer<Vertex>(&vertices[0], vertex_count); ib = GL::IndexBuffer<index_t>(&indices[0], index_count); } |
Dieser Beitrag wurde bereits 7 mal editiert, zuletzt von »dot« (04.09.2010, 00:06)
Und warum ein "a" für "array", wenn du zB für vector keine besondere notation verwendest?
Weil ein Vector eben eine einfache Struktur ist und ein Array einen Speicherblock bezeichnet, den man anders handhabt, als Strukturen oder einfache Variablen.
Und zur Länge von Klassen und Funktionen: Es gibt sehr wohl Fälle, wo eine Funktion 100-200 Zeilen lang ist und wo es keinen Sinn macht, die Funktion in 10 Teilfunktionen auszulagern.
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
Kommentare sind Code-Smell und würden in diesem Fall darauf hindeuten, dass der Code zu lang und unübersichtlich ist.
Was mich an solchem "Lange Methoden aufsplitten" nur immer stört, das ist der Overhead im Code. Da entstehen dann oft 3-4 Methoden, die nur zur Lesbarkeit einer einzelnen Methode beitragen, aber sonst nur die Lesbarkeit der gesamten Klasse verschlimmern und diese scheinbar aufblähen. Lösungsvorschläge um beides 'sauber' zu bekommen?
Quellcode |
|
1 2 3 4 5 6 7 8 9 |
function blablubb(a, b) { c = machirgendwas(a) d = tuwasanderes(b) e = berechneergebnis(c, d) debug(e) return e } |
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
Werbeanzeige