stinkey
Forum adept
- Joined
- Sep 8, 2020
- Messages
- 225
- Reaction score
- 74
Pretty much what the title says. Let's create a list of "y'all need to stop with this softcoding stuff" translations.
By the way, try not to translate the entire thing with Google Translate or something of the type. Inaccuracies, bad translations; also kinda feels like it misses the point
vous devez arrêter avec ce truc appelé "code doux":
Vous référez généralement à enlever le code qui se répète - et oui, cela est une bonne chose, normalement.
Par contre, il y a deux problèmes avec l'attitude autour de cela.
Premièrement, ce n'est pas toutes les situations qui nécéssitent ce type de structure de code. C'est surtout vrai pour des jeux moins ambitieux créés par des nouveaux développeurs. On ne devrait pas éviter d'ajouter certaines choses simplement parce que, dans un jeu "bien codé", ce n'est pas nécessaire. Ce deuxième argument ne s'applique pas spécifiquement à cette conversation, mais je le vois souvent,donc voici: beaucoup de personnes le prend trop au sérieux.
J'ai vu tellement de jeux où ils font des choses extrêmes comme apparaître des items sur le sol pour charger de l'information et autres choses. Ceci n'est pas une bonne idée. Ne sacrifiez pas la facilité à lire le code et son efficacité simplement car ça rend le codage plus facile. Il y a une fine balance entre le code bien désignée, facile à garder et efficace. Coder doucement n'est pas toujours la façon d'atteindre cette balance. Donc s'il vous plaît, juste penser aux systèmes que vous désignez et si quelque chose est vraiment amélioré ou pas.
bref, l'élitisme à travers "des meilleures façons" / le code doux n'aide pas toujours, et n'est souvent pas la bonne réponse.
Vous référez généralement à enlever le code qui se répète - et oui, cela est une bonne chose, normalement.
Par contre, il y a deux problèmes avec l'attitude autour de cela.
Premièrement, ce n'est pas toutes les situations qui nécéssitent ce type de structure de code. C'est surtout vrai pour des jeux moins ambitieux créés par des nouveaux développeurs. On ne devrait pas éviter d'ajouter certaines choses simplement parce que, dans un jeu "bien codé", ce n'est pas nécessaire. Ce deuxième argument ne s'applique pas spécifiquement à cette conversation, mais je le vois souvent,donc voici: beaucoup de personnes le prend trop au sérieux.
J'ai vu tellement de jeux où ils font des choses extrêmes comme apparaître des items sur le sol pour charger de l'information et autres choses. Ceci n'est pas une bonne idée. Ne sacrifiez pas la facilité à lire le code et son efficacité simplement car ça rend le codage plus facile. Il y a une fine balance entre le code bien désignée, facile à garder et efficace. Coder doucement n'est pas toujours la façon d'atteindre cette balance. Donc s'il vous plaît, juste penser aux systèmes que vous désignez et si quelque chose est vraiment amélioré ou pas.
bref, l'élitisme à travers "des meilleures façons" / le code doux n'aide pas toujours, et n'est souvent pas la bonne réponse.
你们需要停止做这些“软码”东西：
你们一般在说去掉重复的代码；这一般也是好的。问题是，关于这个的想法有两个问题。
首先，不是每个情况都需要这样的代码结构，特别是对编程序不太熟的人做的小游戏。我们不应该避免加生活质量功能仅仅因为在使用“正确编码方式”的游戏里这些会用不着。第二点没有特别的包括在这个谈话中，可是我常常看到它被提出，如此我就继续说：很多人做的过了。
我看到过太多游戏做跟在地上生成物品来负载数据类似的东西。这是不好的。别为了一个更好的编码体验牺牲程序易读性和效率。编有精心设计、好保持、和高效率的程序之中有很仔细的平衡。有事，软码不是最好达到这个平衡的方式。所我求你，想想你设计的结构的效果，真的有没有好处。
太长；没读：通过“更好作法”或软码来追求精英主义没有用，很多时不是正确的方案。
你们一般在说去掉重复的代码；这一般也是好的。问题是，关于这个的想法有两个问题。
首先，不是每个情况都需要这样的代码结构，特别是对编程序不太熟的人做的小游戏。我们不应该避免加生活质量功能仅仅因为在使用“正确编码方式”的游戏里这些会用不着。第二点没有特别的包括在这个谈话中，可是我常常看到它被提出，如此我就继续说：很多人做的过了。
我看到过太多游戏做跟在地上生成物品来负载数据类似的东西。这是不好的。别为了一个更好的编码体验牺牲程序易读性和效率。编有精心设计、好保持、和高效率的程序之中有很仔细的平衡。有事，软码不是最好达到这个平衡的方式。所我求你，想想你设计的结构的效果，真的有没有好处。
太长；没读：通过“更好作法”或软码来追求精英主义没有用，很多时不是正确的方案。
hepinizin herşeyi softcodelamak'tan sakınmanız gerekiyor:
Genelde tekrarlanan kodu kaldırmaktan bahsediyorsunuz - ve evet, bu normalde iyi bir şeydir. Ancak, bu konudaki tutumla ilgili iki sorun vardır.
İlk olarak, her durum bu tür kod yapısını zorunlu kılmaz. Bu, özellikle yeni geliştiriciler tarafından yapılan daha küçük oyunlar için geçerlidir. Sadece "düzgün" kodlanmış bir oyunda gerekli olmadığı için belirli yaşam kalitesi özelliklerini eklemekten kaçınmamalıyız. Bu ikinci nokta, özellikle bu konuşma için geçerli değil ama sık sık gündeme geldiğini görüyorum, işte burada: birçok insan bu şekilde kodlamakta çok abartıyor.
Bilgi kaydetmek için yere öğeler inşa etmek gibi çılgınca şeyler yaptıkları pek çok oyun gördüm. Bu iyi değil. Kodlama deneyimini kolaylaştırdığına inandığınız için kodun okunaklılığından ve verimliliğinden ödün vermeyin. İyi tasarlanmış, bakımı kolay ve verimli kod arasında hassas bir denge vardır. Bu dengeyi sağlamanın yolu her zaman softcodelama değildir. Bu yüzden lütfen tasarladığınız sistemleri ve herhangi bir şeyin gerçekten geliştirilip geliştirilmediğini düşünün.
Kısacası, "daha iyi kodlama adetleri"/softcodelama yoluyla elitizm yardımcı olmuyor ve çoğu zaman doğru cevap değildir
Genelde tekrarlanan kodu kaldırmaktan bahsediyorsunuz - ve evet, bu normalde iyi bir şeydir. Ancak, bu konudaki tutumla ilgili iki sorun vardır.
İlk olarak, her durum bu tür kod yapısını zorunlu kılmaz. Bu, özellikle yeni geliştiriciler tarafından yapılan daha küçük oyunlar için geçerlidir. Sadece "düzgün" kodlanmış bir oyunda gerekli olmadığı için belirli yaşam kalitesi özelliklerini eklemekten kaçınmamalıyız. Bu ikinci nokta, özellikle bu konuşma için geçerli değil ama sık sık gündeme geldiğini görüyorum, işte burada: birçok insan bu şekilde kodlamakta çok abartıyor.
Bilgi kaydetmek için yere öğeler inşa etmek gibi çılgınca şeyler yaptıkları pek çok oyun gördüm. Bu iyi değil. Kodlama deneyimini kolaylaştırdığına inandığınız için kodun okunaklılığından ve verimliliğinden ödün vermeyin. İyi tasarlanmış, bakımı kolay ve verimli kod arasında hassas bir denge vardır. Bu dengeyi sağlamanın yolu her zaman softcodelama değildir. Bu yüzden lütfen tasarladığınız sistemleri ve herhangi bir şeyin gerçekten geliştirilip geliştirilmediğini düşünün.
Kısacası, "daha iyi kodlama adetleri"/softcodelama yoluyla elitizm yardımcı olmuyor ve çoğu zaman doğru cevap değildir
أنتم بحاجة إلى التوقف عن المبالغة في إستخدام البرمجة المرنة:
أنت تشير عمومًا إلى إزالة الكود المكرر - ونعم، هذا شيء جيد، عادةً. ومع ذلك، هناك مشكلتان تنتج عن هذا السلوك.
أولاً ، ليس كل موقف يتطلب هذا النوع من بنية الكود. هذا ينطبق بشكل خاص على الألعاب الصغيرة التي تم إنشاؤها بواسطة مطورين جدد. يجب ألا نتجنب إضافة ميزات لتسهيل الحياة لمجرد أنه ليس ضروريًا في لعبة مبرمجة بـ"شكلٍ صحيح". لا تنطبق هذه النقطة الثانية على وجه التحديد على هذه المحادثة، لكنني أرى أنها تظهر بشكل متكرر، لذا سأشرح المشكلة: الكثير من الناس يبالغون للغاية في إستخدام هذا السلوك في البرمجة.
لقد رأيت الكثير من الألعاب حيث يقومون بأشياء مجنونة مثل إنشاء العناصر على الأرض لحفظ المعلومات المعلومات وما إلى ذلك. هذا ليس جيدًا. لا تضحي بسهولة قراءة الكود وكفاءته لمجرد اعتقادك أنه يجعل تجربة البرمجة أسهل. هناك توازن دقيق في الكود المصمم جيدًا، سهل الصيانة والفعال. لا تعد البرمجة المرنة الطريقة الأفضل دائمًا لتحقيق هذا التوازن. لذا من فضلك، فكر فقط في الأنظمة التي تصممها وما إذا كان أي شيء قد تم تحسينه أم لا.
بإختصار، الإعتقاد بأن إستخدام "عادات البرمجة المثلى" أو البرمجة المرنة هي الطريقة الأفضل دائماً هو إعتقادٌ خاطئ، وغالبًا لا يكون الإجابة الصحيحة
أنت تشير عمومًا إلى إزالة الكود المكرر - ونعم، هذا شيء جيد، عادةً. ومع ذلك، هناك مشكلتان تنتج عن هذا السلوك.
أولاً ، ليس كل موقف يتطلب هذا النوع من بنية الكود. هذا ينطبق بشكل خاص على الألعاب الصغيرة التي تم إنشاؤها بواسطة مطورين جدد. يجب ألا نتجنب إضافة ميزات لتسهيل الحياة لمجرد أنه ليس ضروريًا في لعبة مبرمجة بـ"شكلٍ صحيح". لا تنطبق هذه النقطة الثانية على وجه التحديد على هذه المحادثة، لكنني أرى أنها تظهر بشكل متكرر، لذا سأشرح المشكلة: الكثير من الناس يبالغون للغاية في إستخدام هذا السلوك في البرمجة.
لقد رأيت الكثير من الألعاب حيث يقومون بأشياء مجنونة مثل إنشاء العناصر على الأرض لحفظ المعلومات المعلومات وما إلى ذلك. هذا ليس جيدًا. لا تضحي بسهولة قراءة الكود وكفاءته لمجرد اعتقادك أنه يجعل تجربة البرمجة أسهل. هناك توازن دقيق في الكود المصمم جيدًا، سهل الصيانة والفعال. لا تعد البرمجة المرنة الطريقة الأفضل دائمًا لتحقيق هذا التوازن. لذا من فضلك، فكر فقط في الأنظمة التي تصممها وما إذا كان أي شيء قد تم تحسينه أم لا.
بإختصار، الإعتقاد بأن إستخدام "عادات البرمجة المثلى" أو البرمجة المرنة هي الطريقة الأفضل دائماً هو إعتقادٌ خاطئ، وغالبًا لا يكون الإجابة الصحيحة
Trebuie să vă opriți din chestia asta cu codarea moale:
În general, vă referiți la eliminarea codului repetat - și da, este un lucru bun, în mod normal, dar sunt două probleme cu atitudinea despre asta.
În primul rând, nu fiecare situație are nevoie de acest fel de structură a codului, mai ales în jocurile mai mici create de programatori noi. Nu trebuie să evităm adăugarea unor anumite lucruri doar pentru că într-un joc care este programat "corect" nu sunt necesare. A doua problemă nu se aplică specific acestei conversații, dar o văd deseori, deci iată: foarte mulți oameni duc asta mult prea departe.
Am văzut atât de multe jocuri în care fac lucruri nebunești precum crearea itemelor pentru a încărca informații și altele. Nu este bine. Nu sacrifica legibilitatea și eficiența codului doar pentru că crezi că face experiența programatului mai ușoară. Este o balanță delicată între codul bine proiectat, ușor de menținut și eficient. Codarea moale nu este mereu modul de a obține această balanță. Deci vă rog, gandițivă despre sistemele care le proiectați și dacă ceva este de fapt îmbunătățit.
tl;dr elitismul prin "practici mai bune" / cod moale nu ajută, și de obicei nu este răspunsul potrivit.
În general, vă referiți la eliminarea codului repetat - și da, este un lucru bun, în mod normal, dar sunt două probleme cu atitudinea despre asta.
În primul rând, nu fiecare situație are nevoie de acest fel de structură a codului, mai ales în jocurile mai mici create de programatori noi. Nu trebuie să evităm adăugarea unor anumite lucruri doar pentru că într-un joc care este programat "corect" nu sunt necesare. A doua problemă nu se aplică specific acestei conversații, dar o văd deseori, deci iată: foarte mulți oameni duc asta mult prea departe.
Am văzut atât de multe jocuri în care fac lucruri nebunești precum crearea itemelor pentru a încărca informații și altele. Nu este bine. Nu sacrifica legibilitatea și eficiența codului doar pentru că crezi că face experiența programatului mai ușoară. Este o balanță delicată între codul bine proiectat, ușor de menținut și eficient. Codarea moale nu este mereu modul de a obține această balanță. Deci vă rog, gandițivă despre sistemele care le proiectați și dacă ceva este de fapt îmbunătățit.
tl;dr elitismul prin "practici mai bune" / cod moale nu ajută, și de obicei nu este răspunsul potrivit.
||'ᔑꖎꖎ リᒷᒷ↸ ℸ ̣ 𝙹 ᓭℸ ̣ 𝙹!¡ ∴╎ℸ ̣ ⍑ ℸ ̣ ⍑╎ᓭ ᓭ𝙹⎓ℸ ̣ ᓵ𝙹↸╎リ⊣ ᓭℸ ̣ ⚍⎓⎓:
y𝙹⚍'∷ᒷ ⊣ᒷリᒷ∷ᔑꖎꖎ|| ∷ᒷ⎓ᒷ∷∷╎リ⊣ ℸ ̣ 𝙹 ∷ᒷᒲ𝙹⍊╎リ⊣ ∷ᒷ!¡ᒷᔑℸ ̣ ᒷ↸ ᓵ𝙹↸ᒷ – ᔑリ↸ ||ᒷᓭ, ℸ ̣ ⍑╎ᓭ ᔑ ⊣𝙹𝙹↸ ℸ ̣ ⍑╎リ⊣, リ𝙹∷ᒲᔑꖎꖎ||. H𝙹∴ᒷ⍊ᒷ∷, ℸ ̣ ⍑ᒷ∷ᒷ ᔑ∷ᒷ ℸ ̣ ∴𝙹 ╎ᓭᓭ⚍ᒷᓭ ∴╎ℸ ̣ ⍑ ℸ ̣ ⍑ᒷ ᔑℸ ̣ ℸ ̣ ╎ℸ ̣ ⚍↸ᒷ ᔑ∷𝙹⚍リ↸ ℸ ̣ ⍑╎ᓭ.
f╎∷ᓭℸ ̣ , リ𝙹ℸ ̣ ᒷ⍊ᒷ∷|| ᓭ╎ℸ ̣ ⚍ᔑℸ ̣ ╎𝙹リ ᒲᔑリ↸ᔑℸ ̣ ᒷᓭ ℸ ̣ ⍑╎ᓭ ꖌ╎リ↸ 𝙹⎓ ᓵ𝙹↸ᒷ ᓭℸ ̣ ∷⚍ᓵℸ ̣ ⚍∷ᒷ. T⍑╎ᓭ ╎ᓭ ᒷᓭ!¡ᒷᓵ╎ᔑꖎꖎ|| ℸ ̣ ∷⚍ᒷ 𝙹⎓ ᓭᒲᔑꖎꖎᒷ∷ ⊣ᔑᒲᒷᓭ ᒲᔑ↸ᒷ ʖ|| リᒷ∴ᒷ∷ ↸ᒷ⍊ᒷꖎ𝙹!¡ᒷ∷ᓭ. Wᒷ ᓭ⍑𝙹⚍ꖎ↸リ'ℸ ̣ ᔑ⍊𝙹╎↸ ᔑ↸↸╎リ⊣ ᓵᒷ∷ℸ ̣ ᔑ╎リ qol ⎓ᒷᔑℸ ̣ ⚍∷ᒷᓭ ᓭ╎ᒲ!¡ꖎ|| ʖᒷᓵᔑ⚍ᓭᒷ ╎リ ᔑ "!¡∷𝙹!¡ᒷ∷ꖎ||" ᓵ𝙹↸ᒷ↸ ⊣ᔑᒲᒷ ╎ℸ ̣ ╎ᓭリ'ℸ ̣ リᒷᓵᒷᓭᓭᔑ∷||. T⍑╎ᓭ ᓭᒷᓵ𝙹リ↸ !¡𝙹╎リℸ ̣ ↸𝙹ᒷᓭリ'ℸ ̣ ᔑ!¡!¡ꖎ|| ᓭ!¡ᒷᓵ╎⎓╎ᓵᔑꖎꖎ|| ℸ ̣ 𝙹 ℸ ̣ ⍑╎ᓭ ᓵ𝙹リ⍊ᒷ∷ᓭᔑℸ ̣ ╎𝙹リ ʖ⚍ℸ ̣ i ᓭᒷᒷ ╎ℸ ̣ ᓵ𝙹ᒲ╎リ⊣ ⚍!¡ ⎓∷ᒷᑑ⚍ᒷリℸ ̣ ꖎ|| ᓭ𝙹 ⍑ᒷ∷ᒷ ⊣𝙹ᒷᓭ: ᔑ ꖎ𝙹ℸ ̣ 𝙹⎓ !¡ᒷ𝙹!¡ꖎᒷ ℸ ̣ ᔑꖌᒷ ℸ ̣ ⍑╎ᓭ ∴ᔑ|| ℸ ̣ 𝙹𝙹 ⎓ᔑ∷.
i ⍑ᔑ⍊ᒷ ᓭᒷᒷリ ᓭ𝙹 ᒲᔑリ|| !¡ꖎ𝙹ℸ ̣ ᓭ ∴⍑ᒷ∷ᒷ ℸ ̣ ⍑ᒷ|| ↸𝙹 ᓵ∷ᔑ⨅|| ℸ ̣ ⍑╎リ⊣ᓭ ꖎ╎ꖌᒷ ᓭ!¡ᔑ∴リ ╎ℸ ̣ ᒷᒲᓭ 𝙹リ ℸ ̣ ⍑ᒷ ⊣∷𝙹⚍リ↸ ℸ ̣ 𝙹 ꖎ𝙹ᔑ↸ ╎リ⎓𝙹∷ᒲᔑℸ ̣ ╎𝙹リ ᔑリ↸ ∴⍑ᔑℸ ̣ リ𝙹ℸ ̣. T⍑╎ᓭ ╎ᓭ リ𝙹ℸ ̣ ⊣𝙹𝙹↸. D𝙹リ'ℸ ̣ ᓭᔑᓵ∷╎⎓╎ᓵᒷ ᓵ𝙹↸ᒷ ꖎᒷ⊣╎ʖ╎ꖎ╎ℸ ̣ || ᔑリ↸ ᒷ⎓⎓╎ᓵ╎ᒷリᓵ|| ᓭ╎ᒲ!¡ꖎ|| ʖᒷᓵᔑ⚍ᓭᒷ ℸ ̣ ⍑ᒷ|| ʖᒷꖎ╎ᒷ⍊ᒷ ╎ℸ ̣ ᒲᔑꖌᒷᓭ ᓵ𝙹↸╎リ⊣ ᒷ ̇/!¡ᒷ∷╎ᒷリᓵᒷ ᒷᔑᓭ╎ᒷ∷. T⍑ᒷ∷ᒷ ╎ᓭ ᔑ ↸ᒷꖎ╎ᓵᔑℸ ̣ ᒷ ʖᔑꖎᔑリᓵᒷ ʖᒷℸ ̣ ∴ᒷᒷリ ∴ᒷꖎꖎ ↸ᒷᓭ╎⊣リᒷ↸, ᒷᔑᓭ|| ℸ ̣ 𝙹 ᒲᔑ╎リℸ ̣ ᔑ╎リ, ᔑリ↸ ᒷ⎓⎓╎ᓵ╎ᒷリℸ ̣ ᓵ𝙹↸ᒷ. S𝙹⎓ℸ ̣ ᓵ𝙹↸╎リ⊣ ╎ᓭ リ𝙹ℸ ̣ ᔑꖎ∴ᔑ||ᓭ ℸ ̣ ⍑ᒷ ∴ᔑ|| ℸ ̣ 𝙹 ᔑᓵ⍑╎ᒷ⍊ᒷ ℸ ̣ ⍑╎ᓭ ʖᔑꖎᔑリᓵᒷ. S𝙹 !¡ꖎᒷᔑᓭᒷ, ⋮⚍ᓭℸ ̣ ℸ ̣ ⍑╎リꖌ ᔑʖ𝙹⚍ℸ ̣ ℸ ̣ ⍑ᒷ ᓭ||ᓭℸ ̣ ᒷᒲᓭ ||𝙹⚍'∷ᒷ ↸ᒷᓭ╎⊣リ╎リ⊣ ᔑリ↸ ∴⍑ᒷℸ ̣ ⍑ᒷ∷ 𝙹∷ リ𝙹ℸ ̣ ᔑリ||ℸ ̣ ⍑╎リ⊣ ╎ᓭ ᔑᓵℸ ̣ ⚍ᔑꖎꖎ|| ╎ᒲ!¡∷𝙹⍊ᒷ↸.
ℸ ̣ ꖎ;↸∷ ᒷꖎ╎ℸ ̣ ╎ᓭᒲ ℸ ̣ ⍑∷𝙹⚍⊣⍑ "ʖᒷℸ ̣ ℸ ̣ ᒷ∷ !¡∷ᔑᓵℸ ̣ ╎ᓵᒷ" / ᓭ𝙹⎓ℸ ̣ ᓵ𝙹↸╎リ⊣ ↸𝙹ᒷᓭリ'ℸ ̣ ⍑ᒷꖎ!¡, ᔑリ↸ 𝙹⎓ℸ ̣ ᒷリ ╎ℸ ̣ ╎ᓭリ'ℸ ̣ ℸ ̣ ⍑ᒷ ∷╎⊣⍑ℸ ̣ ᔑリᓭ∴ᒷ∷
y𝙹⚍'∷ᒷ ⊣ᒷリᒷ∷ᔑꖎꖎ|| ∷ᒷ⎓ᒷ∷∷╎リ⊣ ℸ ̣ 𝙹 ∷ᒷᒲ𝙹⍊╎リ⊣ ∷ᒷ!¡ᒷᔑℸ ̣ ᒷ↸ ᓵ𝙹↸ᒷ – ᔑリ↸ ||ᒷᓭ, ℸ ̣ ⍑╎ᓭ ᔑ ⊣𝙹𝙹↸ ℸ ̣ ⍑╎リ⊣, リ𝙹∷ᒲᔑꖎꖎ||. H𝙹∴ᒷ⍊ᒷ∷, ℸ ̣ ⍑ᒷ∷ᒷ ᔑ∷ᒷ ℸ ̣ ∴𝙹 ╎ᓭᓭ⚍ᒷᓭ ∴╎ℸ ̣ ⍑ ℸ ̣ ⍑ᒷ ᔑℸ ̣ ℸ ̣ ╎ℸ ̣ ⚍↸ᒷ ᔑ∷𝙹⚍リ↸ ℸ ̣ ⍑╎ᓭ.
f╎∷ᓭℸ ̣ , リ𝙹ℸ ̣ ᒷ⍊ᒷ∷|| ᓭ╎ℸ ̣ ⚍ᔑℸ ̣ ╎𝙹リ ᒲᔑリ↸ᔑℸ ̣ ᒷᓭ ℸ ̣ ⍑╎ᓭ ꖌ╎リ↸ 𝙹⎓ ᓵ𝙹↸ᒷ ᓭℸ ̣ ∷⚍ᓵℸ ̣ ⚍∷ᒷ. T⍑╎ᓭ ╎ᓭ ᒷᓭ!¡ᒷᓵ╎ᔑꖎꖎ|| ℸ ̣ ∷⚍ᒷ 𝙹⎓ ᓭᒲᔑꖎꖎᒷ∷ ⊣ᔑᒲᒷᓭ ᒲᔑ↸ᒷ ʖ|| リᒷ∴ᒷ∷ ↸ᒷ⍊ᒷꖎ𝙹!¡ᒷ∷ᓭ. Wᒷ ᓭ⍑𝙹⚍ꖎ↸リ'ℸ ̣ ᔑ⍊𝙹╎↸ ᔑ↸↸╎リ⊣ ᓵᒷ∷ℸ ̣ ᔑ╎リ qol ⎓ᒷᔑℸ ̣ ⚍∷ᒷᓭ ᓭ╎ᒲ!¡ꖎ|| ʖᒷᓵᔑ⚍ᓭᒷ ╎リ ᔑ "!¡∷𝙹!¡ᒷ∷ꖎ||" ᓵ𝙹↸ᒷ↸ ⊣ᔑᒲᒷ ╎ℸ ̣ ╎ᓭリ'ℸ ̣ リᒷᓵᒷᓭᓭᔑ∷||. T⍑╎ᓭ ᓭᒷᓵ𝙹リ↸ !¡𝙹╎リℸ ̣ ↸𝙹ᒷᓭリ'ℸ ̣ ᔑ!¡!¡ꖎ|| ᓭ!¡ᒷᓵ╎⎓╎ᓵᔑꖎꖎ|| ℸ ̣ 𝙹 ℸ ̣ ⍑╎ᓭ ᓵ𝙹リ⍊ᒷ∷ᓭᔑℸ ̣ ╎𝙹リ ʖ⚍ℸ ̣ i ᓭᒷᒷ ╎ℸ ̣ ᓵ𝙹ᒲ╎リ⊣ ⚍!¡ ⎓∷ᒷᑑ⚍ᒷリℸ ̣ ꖎ|| ᓭ𝙹 ⍑ᒷ∷ᒷ ⊣𝙹ᒷᓭ: ᔑ ꖎ𝙹ℸ ̣ 𝙹⎓ !¡ᒷ𝙹!¡ꖎᒷ ℸ ̣ ᔑꖌᒷ ℸ ̣ ⍑╎ᓭ ∴ᔑ|| ℸ ̣ 𝙹𝙹 ⎓ᔑ∷.
i ⍑ᔑ⍊ᒷ ᓭᒷᒷリ ᓭ𝙹 ᒲᔑリ|| !¡ꖎ𝙹ℸ ̣ ᓭ ∴⍑ᒷ∷ᒷ ℸ ̣ ⍑ᒷ|| ↸𝙹 ᓵ∷ᔑ⨅|| ℸ ̣ ⍑╎リ⊣ᓭ ꖎ╎ꖌᒷ ᓭ!¡ᔑ∴リ ╎ℸ ̣ ᒷᒲᓭ 𝙹リ ℸ ̣ ⍑ᒷ ⊣∷𝙹⚍リ↸ ℸ ̣ 𝙹 ꖎ𝙹ᔑ↸ ╎リ⎓𝙹∷ᒲᔑℸ ̣ ╎𝙹リ ᔑリ↸ ∴⍑ᔑℸ ̣ リ𝙹ℸ ̣. T⍑╎ᓭ ╎ᓭ リ𝙹ℸ ̣ ⊣𝙹𝙹↸. D𝙹リ'ℸ ̣ ᓭᔑᓵ∷╎⎓╎ᓵᒷ ᓵ𝙹↸ᒷ ꖎᒷ⊣╎ʖ╎ꖎ╎ℸ ̣ || ᔑリ↸ ᒷ⎓⎓╎ᓵ╎ᒷリᓵ|| ᓭ╎ᒲ!¡ꖎ|| ʖᒷᓵᔑ⚍ᓭᒷ ℸ ̣ ⍑ᒷ|| ʖᒷꖎ╎ᒷ⍊ᒷ ╎ℸ ̣ ᒲᔑꖌᒷᓭ ᓵ𝙹↸╎リ⊣ ᒷ ̇/!¡ᒷ∷╎ᒷリᓵᒷ ᒷᔑᓭ╎ᒷ∷. T⍑ᒷ∷ᒷ ╎ᓭ ᔑ ↸ᒷꖎ╎ᓵᔑℸ ̣ ᒷ ʖᔑꖎᔑリᓵᒷ ʖᒷℸ ̣ ∴ᒷᒷリ ∴ᒷꖎꖎ ↸ᒷᓭ╎⊣リᒷ↸, ᒷᔑᓭ|| ℸ ̣ 𝙹 ᒲᔑ╎リℸ ̣ ᔑ╎リ, ᔑリ↸ ᒷ⎓⎓╎ᓵ╎ᒷリℸ ̣ ᓵ𝙹↸ᒷ. S𝙹⎓ℸ ̣ ᓵ𝙹↸╎リ⊣ ╎ᓭ リ𝙹ℸ ̣ ᔑꖎ∴ᔑ||ᓭ ℸ ̣ ⍑ᒷ ∴ᔑ|| ℸ ̣ 𝙹 ᔑᓵ⍑╎ᒷ⍊ᒷ ℸ ̣ ⍑╎ᓭ ʖᔑꖎᔑリᓵᒷ. S𝙹 !¡ꖎᒷᔑᓭᒷ, ⋮⚍ᓭℸ ̣ ℸ ̣ ⍑╎リꖌ ᔑʖ𝙹⚍ℸ ̣ ℸ ̣ ⍑ᒷ ᓭ||ᓭℸ ̣ ᒷᒲᓭ ||𝙹⚍'∷ᒷ ↸ᒷᓭ╎⊣リ╎リ⊣ ᔑリ↸ ∴⍑ᒷℸ ̣ ⍑ᒷ∷ 𝙹∷ リ𝙹ℸ ̣ ᔑリ||ℸ ̣ ⍑╎リ⊣ ╎ᓭ ᔑᓵℸ ̣ ⚍ᔑꖎꖎ|| ╎ᒲ!¡∷𝙹⍊ᒷ↸.
ℸ ̣ ꖎ;↸∷ ᒷꖎ╎ℸ ̣ ╎ᓭᒲ ℸ ̣ ⍑∷𝙹⚍⊣⍑ "ʖᒷℸ ̣ ℸ ̣ ᒷ∷ !¡∷ᔑᓵℸ ̣ ╎ᓵᒷ" / ᓭ𝙹⎓ℸ ̣ ᓵ𝙹↸╎リ⊣ ↸𝙹ᒷᓭリ'ℸ ̣ ⍑ᒷꖎ!¡, ᔑリ↸ 𝙹⎓ℸ ̣ ᒷリ ╎ℸ ̣ ╎ᓭリ'ℸ ̣ ℸ ̣ ⍑ᒷ ∷╎⊣⍑ℸ ̣ ᔑリᓭ∴ᒷ∷
Abba kéne már, hogy hagyjátok ezzel a „szoftkódolással”:
Általában az ismétlődő kód eltávolítására hivatkoztok – és valóban, ez legtöbbször tényleg jó dolog. Azonban két gond is van az ilyesfajta hozzáállással.
Először is, nem minden helyzet követel ilyesmi kódszerkezetet. Ez kimondottan igaz az új fejlesztők által alkotott kisebb játékokra. Nem kellene elkerülnünk bizonyos fejlesztés menetét javító funkciók bevezetését egyszerűen azért, mert egy „rendesen” kódolt játékban ilyesmire nincsen szükség. A második érv nem kapcsolódik kimondottan ehhez a témához, de gyakran látom, hogy szóba kerül: rengeteg ember túlságosan is eltúlozza ezt.
Már számtalan olyan játékkal találkoztam, melyekben olyan elmebeteg dolgokat művelnek, mint tárgyak leidézése a földre adatok betöltése érdekében és miegymás. Ez nem jó. Ne áldozd fel a kód olvashatóságát és hatékonyságát egyszerűen azért, mert ők azt gondolják, hogy könnyíti a programozás folyamatát. Létezik egy finom egyensúly a jól tervezett, könnyen kezelhető, és hatékony programban. Tehát kérlek, hogy gondold át az általad tervezett rendszereket, hogy vajon tényleg javítanak-e akármin is.
Röviden: A „jobb gyakorlásból” vagy a szoftkódolásból származó elitizmus nem segít senkin, és gyakran nem ez a hozzáállás a helyes.
Általában az ismétlődő kód eltávolítására hivatkoztok – és valóban, ez legtöbbször tényleg jó dolog. Azonban két gond is van az ilyesfajta hozzáállással.
Először is, nem minden helyzet követel ilyesmi kódszerkezetet. Ez kimondottan igaz az új fejlesztők által alkotott kisebb játékokra. Nem kellene elkerülnünk bizonyos fejlesztés menetét javító funkciók bevezetését egyszerűen azért, mert egy „rendesen” kódolt játékban ilyesmire nincsen szükség. A második érv nem kapcsolódik kimondottan ehhez a témához, de gyakran látom, hogy szóba kerül: rengeteg ember túlságosan is eltúlozza ezt.
Már számtalan olyan játékkal találkoztam, melyekben olyan elmebeteg dolgokat művelnek, mint tárgyak leidézése a földre adatok betöltése érdekében és miegymás. Ez nem jó. Ne áldozd fel a kód olvashatóságát és hatékonyságát egyszerűen azért, mert ők azt gondolják, hogy könnyíti a programozás folyamatát. Létezik egy finom egyensúly a jól tervezett, könnyen kezelhető, és hatékony programban. Tehát kérlek, hogy gondold át az általad tervezett rendszereket, hogy vajon tényleg javítanak-e akármin is.
Röviden: A „jobb gyakorlásból” vagy a szoftkódolásból származó elitizmus nem segít senkin, és gyakran nem ez a hozzáállás a helyes.
Ihr müsst mal mit diesem Soft-Coding zeug aufhören:
Ihr meint einfach generell die Entfernung von sich wiederholenden Code – und ja, das ist ein gutes ding, normaler weise, aber, da sind zwei Probleme damit.
Als erstes, nicht jede Situation unterstützt die Code Struktur. Dies ist am meisten wahr bei kleinen Spielen von neueren Entwicklern. Wir sollten QOL Features nicht ignorieren einfach nur weil in einen "richtig" Entwickelten Spiel sie nicht Nötig sind. Der zweite punkt Hängt nicht wirklich zu dieser Konversation aber ich sehe er kommt öfters vor also hier kommt er: Viele Leute nehmen es zu ernst.
Ich hab so viele Grundstücke gesehen wo sie verrückte dinge tuen wie Items auf dem Boden Spawnen um Information zu laden und anderes zeug. Dies ist nicht gut. Opfere nicht die Code Funktionen und Effizienz einfach weil du glaubst es mach das Programmier Erlebnis einfacher. Es gibt eine einfache Balance zwischen gut designed, einfach sich drum zu kümmer und effizienter Code. Soft-Coding ist nicht immer der weg um die Balance zu kriegen. So bitte, denk einfach über die systeme die du designs und ob etwas oder nichts sich verbessert hat.
tl;dr Elitismus durch "bessere Übung" / Soft-Coding hilft nicht und ist öfters nicht die richtige antwort
Ihr meint einfach generell die Entfernung von sich wiederholenden Code – und ja, das ist ein gutes ding, normaler weise, aber, da sind zwei Probleme damit.
Als erstes, nicht jede Situation unterstützt die Code Struktur. Dies ist am meisten wahr bei kleinen Spielen von neueren Entwicklern. Wir sollten QOL Features nicht ignorieren einfach nur weil in einen "richtig" Entwickelten Spiel sie nicht Nötig sind. Der zweite punkt Hängt nicht wirklich zu dieser Konversation aber ich sehe er kommt öfters vor also hier kommt er: Viele Leute nehmen es zu ernst.
Ich hab so viele Grundstücke gesehen wo sie verrückte dinge tuen wie Items auf dem Boden Spawnen um Information zu laden und anderes zeug. Dies ist nicht gut. Opfere nicht die Code Funktionen und Effizienz einfach weil du glaubst es mach das Programmier Erlebnis einfacher. Es gibt eine einfache Balance zwischen gut designed, einfach sich drum zu kümmer und effizienter Code. Soft-Coding ist nicht immer der weg um die Balance zu kriegen. So bitte, denk einfach über die systeme die du designs und ob etwas oder nichts sich verbessert hat.
tl;dr Elitismus durch "bessere Übung" / Soft-Coding hilft nicht und ist öfters nicht die richtige antwort
Ihr solltet mal mit diesem „softcoding“-Zeug aufhören:
Normalerweise meint ihr damit das entfernen von wiederholten code —
und normalerweise ist das auch etwas gutes. Aber es gibt damit 2 Probleme.
Zu allererst nicht jede Situation unterstützt diese Art des Programmierens. Das trifft vorallem bei kleineren Games von neueren Devs zu. Man sollte bestimmte QOL Features nicht auslassen nur, weil es in einem „gut gecodeten“ Spiel nicht nötig wäre. Das zweite Problem trifft jetzt nicht genau auf dieses Gespräch zu, aber ich habe viele Leute darüber reden hören:
Viele Leute treiben es viel zu weit mit dem „softcoding“.
Ich habe schon sehr viele Plots gesehen wo sie verrückte Sachen machen, wie zum Beispiel Items spawnen um data zu laden. Das ist nicht gut. Gib keine code effizienz auf nur, weil du denkst, dass es coding einfacher macht. Es gibt eine sehr wichtige Balance zwischen gut designed, einfach änderbarem und effizienten code. Softcoding ist nicht immer die Lösung um diese Balance zu erreichen. Also bitte denke über dein System, dass du designst, nach und ob es irgendetwas verbessert.
Normalerweise meint ihr damit das entfernen von wiederholten code —
und normalerweise ist das auch etwas gutes. Aber es gibt damit 2 Probleme.
Zu allererst nicht jede Situation unterstützt diese Art des Programmierens. Das trifft vorallem bei kleineren Games von neueren Devs zu. Man sollte bestimmte QOL Features nicht auslassen nur, weil es in einem „gut gecodeten“ Spiel nicht nötig wäre. Das zweite Problem trifft jetzt nicht genau auf dieses Gespräch zu, aber ich habe viele Leute darüber reden hören:
Viele Leute treiben es viel zu weit mit dem „softcoding“.
Ich habe schon sehr viele Plots gesehen wo sie verrückte Sachen machen, wie zum Beispiel Items spawnen um data zu laden. Das ist nicht gut. Gib keine code effizienz auf nur, weil du denkst, dass es coding einfacher macht. Es gibt eine sehr wichtige Balance zwischen gut designed, einfach änderbarem und effizienten code. Softcoding ist nicht immer die Lösung um diese Balance zu erreichen. Also bitte denke über dein System, dass du designst, nach und ob es irgendetwas verbessert.
כולכם צריכים להפסיק עם ה"קוד רך" הזה:
אתם בכללי מתכוונים להורדת קוד חוזר - וכן, זה דבר טוב, אבל בדרך כלל יש שני בעיות עם ההתנהגות סביב המונח הזה.
קודם כל, לא כל סיטואציה דורשת מבנה קוד כזה, זה במיוחד נכון כשמדובר על משחקים קטנים יותר הנוצרו ע"י מעצבים חדשים. אנחנו לא אמורים להתעלם מתוספות שמוסיפות לאיכות החיים רק בגלל שבמשחק מעוצב "נכון" זה לא הכרחי. הנקודה השנייה לא מתאימה לשיחה הזאת ספציפית אבל אני רואה אותה קמה הרבה פעמים: אנשים לוקחים את זה יותר מידי רחוק.
ראיתי כל כך הרבה משחקים שבהם עושים דברים מטורפים כמו לזרוק פריטים על הקרקע כדי לטעון אינפורמציה ומה לא. זה לא טוב. אל תקריבו קוד פרקטי ויעילות של קוד רק בגלל שאתם מאמינים שזה הופך תכנות לקל יותר. יש איזון אלגנטי בין מעוצב היטב, קל להחזיק, ויעיל. "קוד רך" זה לא תמיד הדרך להשיג את האיזון הזה. אז בבקשה, רק תחשבו על המערכות שאתם מעצבים ואם משהו יהיה משופר מקוד רך.
נ.ב אליטיסם סביב "קוד רך" או "הרגל טוב" לא עוזר, ובדרך כלל לא התשובה הנכונה.
אתם בכללי מתכוונים להורדת קוד חוזר - וכן, זה דבר טוב, אבל בדרך כלל יש שני בעיות עם ההתנהגות סביב המונח הזה.
קודם כל, לא כל סיטואציה דורשת מבנה קוד כזה, זה במיוחד נכון כשמדובר על משחקים קטנים יותר הנוצרו ע"י מעצבים חדשים. אנחנו לא אמורים להתעלם מתוספות שמוסיפות לאיכות החיים רק בגלל שבמשחק מעוצב "נכון" זה לא הכרחי. הנקודה השנייה לא מתאימה לשיחה הזאת ספציפית אבל אני רואה אותה קמה הרבה פעמים: אנשים לוקחים את זה יותר מידי רחוק.
ראיתי כל כך הרבה משחקים שבהם עושים דברים מטורפים כמו לזרוק פריטים על הקרקע כדי לטעון אינפורמציה ומה לא. זה לא טוב. אל תקריבו קוד פרקטי ויעילות של קוד רק בגלל שאתם מאמינים שזה הופך תכנות לקל יותר. יש איזון אלגנטי בין מעוצב היטב, קל להחזיק, ויעיל. "קוד רך" זה לא תמיד הדרך להשיג את האיזון הזה. אז בבקשה, רק תחשבו על המערכות שאתם מעצבים ואם משהו יהיה משופר מקוד רך.
נ.ב אליטיסם סביב "קוד רך" או "הרגל טוב" לא עוזר, ובדרך כלל לא התשובה הנכונה.
b'doo qhhg wr vwrs zlwk wklv vriwfrglqj vwxii:
Brx'uh jhqhudoob uhihuulqj wr uhprylqj uhshdwhg frgh – dqg bhv, wklv d jrrg wklqj, qrupdoob. Krzhyhu, wkhuh duh wzr lvvxhv zlwk wkh dwwlwxgh durxqg wklv.
Iluvw, qrw hyhub vlwxdwlrq pdqgdwhv wklv nlqg ri frgh vwuxfwxuh. Wklv lv hvshfldoob wuxh ri vpdoohu jdphv pdgh eb qhzhu ghyhorshuv. Zh vkrxogq'w dyrlg dgglqj fhuwdlq TRO ihdwxuhv vlpsob ehfdxvh lq d "surshuob" frghg jdph lw lvq'w qhfhvvdub. Wklv vhfrqg srlqw grhvq'w dssob vshflilfdoob wr wklv frqyhuvdwlrq exw L vhh lw frplqj xs iuhtxhqwob vr khuh jrhv: d orw ri shrsoh wdnh wklv zdb wrr idu.
L kdyh vhhq vr pdqb sorwv zkhuh wkhb gr fudcb wklqjv olnh vsdzq lwhpv rq wkh jurxqg wr ordg lqirupdwlrq dqg zkdwqrw. Wklv lv qrw jrrg. Grq'w vdfulilfh frgh ohjlelolwb dqg
hiilflhqfb vlpsob ehfdxvh wkhb eholhyh lw pdnhv frglqj hashulhqfh hdvlhu. Wkhuh lv d gholfdwh edodqfh ehwzhhq zhoo ghvljqhg, hdvb wr pdlqwdlq, dqg hiilflhqw frgh. Vriwfrglqj lv qrw dozdbv wkh zdb wr dfklhyh wklv edodqfh. Vr sohdvh, mxvw wklqn derxw wkh vbvwhpv brx'uh ghvljqlqj dqg zkhwkhu ru qrw dqbwklqj lv dfwxdoob lpsuryhg.
wo;gu holwlvp wkurxjk "ehwwhu sudfwlfh" / vriwfrglqj grhvq'w khos, dqg riwhq lw lvq'w wkh uljkw dqvzhu
Brx'uh jhqhudoob uhihuulqj wr uhprylqj uhshdwhg frgh – dqg bhv, wklv d jrrg wklqj, qrupdoob. Krzhyhu, wkhuh duh wzr lvvxhv zlwk wkh dwwlwxgh durxqg wklv.
Iluvw, qrw hyhub vlwxdwlrq pdqgdwhv wklv nlqg ri frgh vwuxfwxuh. Wklv lv hvshfldoob wuxh ri vpdoohu jdphv pdgh eb qhzhu ghyhorshuv. Zh vkrxogq'w dyrlg dgglqj fhuwdlq TRO ihdwxuhv vlpsob ehfdxvh lq d "surshuob" frghg jdph lw lvq'w qhfhvvdub. Wklv vhfrqg srlqw grhvq'w dssob vshflilfdoob wr wklv frqyhuvdwlrq exw L vhh lw frplqj xs iuhtxhqwob vr khuh jrhv: d orw ri shrsoh wdnh wklv zdb wrr idu.
L kdyh vhhq vr pdqb sorwv zkhuh wkhb gr fudcb wklqjv olnh vsdzq lwhpv rq wkh jurxqg wr ordg lqirupdwlrq dqg zkdwqrw. Wklv lv qrw jrrg. Grq'w vdfulilfh frgh ohjlelolwb dqg
hiilflhqfb vlpsob ehfdxvh wkhb eholhyh lw pdnhv frglqj hashulhqfh hdvlhu. Wkhuh lv d gholfdwh edodqfh ehwzhhq zhoo ghvljqhg, hdvb wr pdlqwdlq, dqg hiilflhqw frgh. Vriwfrglqj lv qrw dozdbv wkh zdb wr dfklhyh wklv edodqfh. Vr sohdvh, mxvw wklqn derxw wkh vbvwhpv brx'uh ghvljqlqj dqg zkhwkhu ru qrw dqbwklqj lv dfwxdoob lpsuryhg.
wo;gu holwlvp wkurxjk "ehwwhu sudfwlfh" / vriwfrglqj grhvq'w khos, dqg riwhq lw lvq'w wkh uljkw dqvzhu
jullie moeten stoppen met dit zacht programmeren:
Jullie bedoelen over het algemeen naar het verwijderen van herhaalde code - en ja, dit is goed, normaal. Daar in tegen zijn er twee problemen met de houding hieromheen.
Om te beginnen, niet elke situatie heeft dit soort structuur nodig. Dit is vooral waar bij kleinere spellen gemaakt door nieuwere makers. We moeten het toevoegen van bepaalde QOL features niet uit de weg gaan puur omdat in een "juist" geprogrammeerde game dat niet nodig is. Dit tweede punt is niet van toepassing op deze conversatie maar ik zie het vaak genoeg: veel mensen nemen dit te ver.
ik heb zo veel plots gezien waar ze rare dingen doen zoals objecten creëren op de grond om informatie in te laden enzo. Dit is niet goed, Geef leesbaarheid en efficiëntie niet op alleen omdat ze geloven dat het het programmeren makkelijker maakt. Er is een delicate balans tussen goed gemaakte, makkelijk te onderhouden en efficiënte code. Zacht programmeren is niet altijd de manier om deze balans te bereiken. Dus alsjeblieft, denk na over de systemen die je maakt en of er iets wordt verbeterd.
kortom, elitisme door "juist programmeren"/ zacht programmeren helpt niet, en is vaak niet het juiste antwoord
Jullie bedoelen over het algemeen naar het verwijderen van herhaalde code - en ja, dit is goed, normaal. Daar in tegen zijn er twee problemen met de houding hieromheen.
Om te beginnen, niet elke situatie heeft dit soort structuur nodig. Dit is vooral waar bij kleinere spellen gemaakt door nieuwere makers. We moeten het toevoegen van bepaalde QOL features niet uit de weg gaan puur omdat in een "juist" geprogrammeerde game dat niet nodig is. Dit tweede punt is niet van toepassing op deze conversatie maar ik zie het vaak genoeg: veel mensen nemen dit te ver.
ik heb zo veel plots gezien waar ze rare dingen doen zoals objecten creëren op de grond om informatie in te laden enzo. Dit is niet goed, Geef leesbaarheid en efficiëntie niet op alleen omdat ze geloven dat het het programmeren makkelijker maakt. Er is een delicate balans tussen goed gemaakte, makkelijk te onderhouden en efficiënte code. Zacht programmeren is niet altijd de manier om deze balans te bereiken. Dus alsjeblieft, denk na over de systemen die je maakt en of er iets wordt verbeterd.
kortom, elitisme door "juist programmeren"/ zacht programmeren helpt niet, en is vaak niet het juiste antwoord
Vocês precisam parar com essas coisas de softcoding:
Você geralmente está se referindo à remoção de código repetido - e sim, isso é uma coisa boa, normalmente. No entanto, há dois problemas com a atitude em torno disso.
Primeiro, nem toda situação exige esse tipo de estrutura de código. Isso é especialmente verdadeiro para jogos menores feitos por desenvolvedores mais novatos. Não devemos evitar adicionar certos recursos de QOL simplesmente porque em um jogo codificado "apropriadamente" isso não é necessário. Este segundo ponto não se aplica especificamente a esta conversa, mas eu vejo isso surgindo com frequência, então aqui vai: muitas pessoas vão longe demais.
Eu vi tantas plots onde eles fazem coisas malucas como spawnar itens no solo para carregar informações e outros enfeites. Isto não é bom. Não sacrifique a legibilidade e a eficiência do código simplesmente porque acreditam que isso torna a experiência de codificação mais fácil. Existe um equilíbrio delicado entre código bem projetado, fácil de manter e eficiente. Softcoding nem sempre é a maneira de atingir esse equilíbrio. Então, por favor, pense apenas nos sistemas que você está projetando e se alguma coisa foi realmente melhorada ou não.
tl; dr elitismo por meio de "melhores práticas" / softcoding não ajuda e, muitas vezes, não é a resposta certa
Você geralmente está se referindo à remoção de código repetido - e sim, isso é uma coisa boa, normalmente. No entanto, há dois problemas com a atitude em torno disso.
Primeiro, nem toda situação exige esse tipo de estrutura de código. Isso é especialmente verdadeiro para jogos menores feitos por desenvolvedores mais novatos. Não devemos evitar adicionar certos recursos de QOL simplesmente porque em um jogo codificado "apropriadamente" isso não é necessário. Este segundo ponto não se aplica especificamente a esta conversa, mas eu vejo isso surgindo com frequência, então aqui vai: muitas pessoas vão longe demais.
Eu vi tantas plots onde eles fazem coisas malucas como spawnar itens no solo para carregar informações e outros enfeites. Isto não é bom. Não sacrifique a legibilidade e a eficiência do código simplesmente porque acreditam que isso torna a experiência de codificação mais fácil. Existe um equilíbrio delicado entre código bem projetado, fácil de manter e eficiente. Softcoding nem sempre é a maneira de atingir esse equilíbrio. Então, por favor, pense apenas nos sistemas que você está projetando e se alguma coisa foi realmente melhorada ou não.
tl; dr elitismo por meio de "melhores práticas" / softcoding não ajuda e, muitas vezes, não é a resposta certa
By the way, try not to translate the entire thing with Google Translate or something of the type. Inaccuracies, bad translations; also kinda feels like it misses the point
Last edited:
