لماذا يحب الناس حساسية الحالة؟[مغلق]

Question

فقط أتساءل لماذا يحب الناس حساسية الحالة في لغة البرمجة؟أنا لا أحاول أن أبدأ حرب اللهب فقط أشعر بالفضول، هذا كل شيء.
أنا شخصياً لم أحبها أبدًا لأنني وجدت أن إنتاجيتي تنخفض عندما جربت لغة ذات حساسية لحالة الأحرف، مع العلم أنني بدأت في الإحماء/التعود عليها ببطء الآن بعد أن أصبحت أستخدم C# وF# كثيرًا. انا اعتدت على.

فلماذا يعجبك؟

هتافات

Answer 1

والاتساق. متاحة أكثر صعوبة في القراءة إذا "فو"، "فو"، "فو"، و "فو" تعتبر متطابقة.

وSOME PEOPLE سيكتب كل شيء في ALL CAPS، مما يجعل كل شيء أقل قابلية للقراءة.

وحساسية القضية يجعل من السهل استخدام "نفس الاسم" بطرق مختلفة، وفقا لاتفاقية القيمة، منها مثلا،

Foo foo = ...  // "Foo" is a type, "foo" is a variable with that type

Answer 2

وميزة من VB.NET هي أنه على الرغم من أنها ليست لحالة الأحرف، وIDE تلقائيا إعادة تنسيقات كل شيء إلى حالة "الرسمية" لمعرف الذي تستخدمه - لذلك فمن السهل أن تكون متسقة، وسهلة القراءة.

والعيب هو أنني أكره النحو على غرار VB، ويفضل الكثير مشغلي الطراز C، وعلامات الترقيم وبناء الجملة.

في C # أجد أنا دائما ضرب على Ctrl-الفضاء لإنقاذ الحاجة إلى استخدام النوع المناسب.

وفقط لأن يمكنك تسمية الأشياء التي تختلف فقط من قبل الحالة لا يعني انها فكرة جيدة، لأنه يمكن أن يؤدي إلى سوء الفهم إذا كان الكثير من تلك التسريبات إلى نطاقات أوسع، لذلك أوصي توجيه واضح من ذلك في تطبيق أو على مستوى النظام الفرعي، ولكن يسمح لها فقط داخليا إلى وظيفة أو طريقة أو فئة.

Answer 3

وحساسية القضية لا تطبق الترميز الأساليب أو الاتساق. إذا كنت باسكال الحالة مستمرة، فإن المترجم لا يشكو. انها سوف فقط يجبرك على اكتبه في استخدام حالة باسكال كل مرة تستخدم فيها. أنا شخصيا أجد أنه غضب لدينا لمحاولة التمييز بين البنود التي تختلف فقط في حالة. فمن السهل القيام به في كتلة قصيرة من التعليمات البرمجية، ولكن من الصعب جدا للحفاظ على التوالي في كتلة كبيرة جدا من التعليمات البرمجية. ولاحظ أيضا أن الطريقة الشعب الوحيد يمكن استخدامها في الواقع حساسية القضية دون الذهاب المكسرات هو إذا كانت جميع اتباع جامد اصطلاحات التسمية نفسها. هو اصطلاح التسمية التي أضافت قيمة، وليس حساسية القضية.

Answer 4

وأنا الحفاظ على المترجم الداخلي لشركتي، وأنا يميل لجعله هجين - يمكنك استخدام أي حال كنت تريد لمعرف، وعليك أن تشير إليها بنفس الغلاف، ولكن تسمية شيء آخر مع سوف يحمل نفس الاسم وحالة مختلفة تسبب خطأ.

Dim abc = 1
Dim y = Abc - 1 ' error, case doesn't match "abc"
Dim ABC = False ' error, can't redeclare variable "abc"

وانها حاليا حساس لحالة الأحرف، لذلك ربما أتمكن من إصلاح بعض الأخطاء الموجودة ولا أحد يشكو الكثير ...

Answer 5

وكثير من الناس الذين يحبون الإفرادية <م> حساسية يسيئون فهم ما الإفرادية في حساسية تعني.

وVB. NET هو تحسس حالة الأحرف. هذا لا يعني أنه يمكنك تعريف متغير كما حروف، ثم ترجع بعد ذلك إلى أنها ABC، اي بي سي، وايه بي سي. وهذا يعني أنه إذا كنت اكتبه عن أي من تلك الآخرين، وIDE سوف تتغير تلقائيا إلى الشكل الصحيح.

والحساسية لحالة الأحرف يعني يمكنك كتابة

dim a as string

ووسوف VS تغييره تلقائيا إلى صحيح فتش

Dim a As String

في الممارسة العملية، وهذا يعني أنك أبدا تقريبا لديهم لضرب مفتاح Shift، لأنك يمكن أن اكتب في كل صغيرة والسماح للIDE الصحيح بالنسبة لك.

ولكن C # ليس سيئا للغاية حول هذا كما كانت عليه من قبل. التحسس في C # هو أكثر عدوانية بكثير مما كانت عليه في VS 2002 و 2003، حتى أن عدد ضغطة يسقط قليلا جدا.

Answer 6

وأعتقد أنه يفرض الاتساق، مما يحسن من سهولة قراءة التعليمات البرمجية، ويتيح عينك تحليل من القطع على نحو أفضل.

class Doohickey {

  public void doSomethingWith(string things) {
     print(things);
  }
}

وعن طريق الاتفاقيات غلاف يجعل هذا الرمز يظهر standarized جدا لأي مبرمج. يمكنك انتقاء الطبقات، وأنواع وأساليب بسهولة. سيكون أصعب بكثير أن تفعل إذا كان أي شخص يمكن أن تستفيد بأي شكل من الأشكال:

Class DOOHICKEY {
  Public Void dosomethingwith(string Things) {
    Print(things);
  }
} 

ولا يعني أن الناس سوف كتابة رمز قبيح، ولكن الكثير في الطريق الرسملة وعلامات الترقيم وقواعد تجعل الكتابة أسهل في القراءة، حساسية القضية أو غلاف معايير جعل رمز أسهل للقراءة.

Answer 7

وأعتقد أنه من المهم أن تفهم الفرق بين ما هو حساسية القضية وما هي قراءة للإجابة على هذا صحيح. في حين وجود استراتيجيات مختلفة غلاف مفيد، هل يمكن أن يكون لهم ضمن لغة غير حساس لحالة الأحرف.

وعلى سبيل المثال فو يمكن استخدامها لمتغير وFOO كما ثابت في كل من يافا وVB. هناك اختلاف بسيط أن VB تسمح لك لكتابة فو في وقت لاحق، ولكن هذا في الغالب مسألة القراءة ونأمل أن يتم إصلاحها من خلال شكل من أشكال إنجاز قانون.

وماذا يمكن أن تكون مفيدة للغاية عندما كنت تريد أن حالات من الأشياء الخاصة بك. إذا كنت تستخدم اصطلاح التسمية متسقة يمكن أن تصبح السهل جدا أن نرى من أين تأتي الأشياء الخاصة بك من.

وعلى سبيل المثال: FooBar fooBar = جديدة FooBar ()؛

وعندما تكون هناك حاجة كائن واحد فقط من نوع، قراءة يزداد بشكل كبير كما هو واضح على الفور ما هو كائن. عندما تكون هناك حاجة مثيلات متعددة، سيكون لديك الواضح أن اختيار (أسماء ذات مغزى أمل) جديدة، ولكن في أقسام رمز صغير يجعل الكثير من معنى لاستخدام اسم فئة مع الحرف الأول صغيرة بدلا من نظام مثل myFooBar، س، أو بعض القيمة التعسفية الأخرى التي سوف لن ننسى ما تقوم به.

وبالطبع كل هذا يبعث على السياق، ولكن في هذا السياق أقول 9 مرات من أصل 10 فإنه يؤتي ثماره.

Answer 8

وهناك الكثير من الإجابات هنا، ولكن أنا مندهش وأشار أحدا من المثال الواضح أن يجعل أيضا متعة منافس ستاكوفيرفلوو:

expertSexChange != expertsExchange

والقضية هي مهمة جدا عند استخدام أسماء المتغيرات حالة الجمال.

Answer 9

فهو يوفر لك المزيد من الخيارات.

وبيل جرس جرس

وكلها مختلفة.

وعلاوة على ذلك، يدفع نوبي التي كانت مستأجرة فقط المكسرات في محاولة لمعرفة لماذا مجاميع لا يخرجون اليمنى. س)))

Answer 10

ولأن الآن لديك فعلا لكتابة كل شيء بطريقة متسقة. ومن ثم تبدأ الأمور فجأة معنى.

إذا كان لديك محرر لائق - واحد الذي يتميز التحسس أو الشيء نفسه باسم آخر - يجب أن لا يكون أي مشاكل في معرفة namees لحالة الأحرف

Answer 11

وحساسية القضية هي الجنون! أي نوع من المبرمج مجنون ستستخدم المتغيرات اسمه فو، فو، فو، وفو جميعا في نفس النطاق؟ عليك أبدا إقناع لي أن هناك سببا لحساسية القضية!

Answer 12

وأعتقد أن هناك أيضا مسألة من علم النفس المعنية هنا. نحن المبرمجين، علينا أن نميز بدقة بين الأشياء. 'ا' ليست هي نفس قيمة ASCII باسم 'A'، وأود أن يشعر الغريب عندما يرى مترجم بلدي لهم نفس الشيء. هذا هو السبب، عندما كنت اكتب

و(القائمة "أ" ب "ج)

وفي LISP (في REPL)، وأنه يستجيب مع

و(A B C)

وذهني على الفور يصيح "هذا ليس ما قلته!". عندما تكون الأمور ليست هي نفسها، فإنها <م> هي مختلفة، ويجب أن يكون ذلك في الاعتبار ...

Answer 13

وأنا عادة قضاء بعض الوقت مع البرمجة دلفي في إجازة، وأكثر من وقت آخر أنا فقط استخدام C ++ وMASM. وشيء واحد غريب: عندما أكون في دلفي، وأنا لا أحب حساسية القضية، ولكن عندما أكون على C ++ - أفعل. أنا أحب حساسية القضية، لأني يجعل كلمات مماثلة (وظائف، والمتغيرات) تبدو متشابهة، وأنا أحب حساسية غير حالة لأنه لا يضع القيود المفرطة على syntaxis.

Answer 14

ومن دليل الإطار الصافي المطور اتفاقيات رسملة ، القضية-الحساسية:

<اقتباس فقرة>   

وجود المبادئ التوجيهية القيمة   فقط لجعل معرفات أسهل لل   قراءة والاعتراف بها. غلاف لا يمكن أن يكون   تستخدم كوسيلة لتجنب اسم   اصطدام بين عناصر المكتبة.

     

ولا تفترض أن جميع البرامج   اللغات تتحسس. هم انهم   ليس. أسماء لا يمكن أن تختلف كل حالة على حدة   وحده.

Answer 15

وانها مفيدة للتمييز بين أنواع في التعليمات البرمجية.

وعلى سبيل المثال في جاوة: إذا كان يبدأ بحرف كبير، ثم على الأرجح فئة. إذا ALL_CAPS لها على الأرجح ثابت.

ويعطي المزيد من التنوع.

Answer 16

ويشعر وكأنه وسيلة أكثر مهنية من الترميز. يجب أن لا تحتاج إلى مترجم لمعرفة ما يقصده.

Answer 17

وشعرت بنفس الطريقة التي كنت منذ زمن طويل عندما كنت تستخدم أكثر VB3 / 4 الكثير. الآن أنا أعمل في المقام الأول C #. ولكن الآن أجد IDE في القيام بعمل كبير لإيجاد الرموز، وإعطاء التحسس جيد على قضايا مختلفة. كما أنه يتيح لي مزيدا من المرونة في التعليمات البرمجية بلدي وأنا يمكن أن يكون لها معنى اختلاف ببنود مع الحالات المختلفة، والتي أفعل الكثير الآن.

Answer 18

وأيضا عادة جيدة إذا العمل الخاص بك في لينكس حيث الرجوع أسماء الملفات حساسة لحالة الأحرف. اضطررت الى ميناء تطبيق Windows كولد فيوجن للعمل في لينكس وكان كابوس المطلق. أيضا بعض قواعد البيانات وحساسية القضية قيد التشغيل، تخيل فرحة هناك.

ومن عادة جيدة على الرغم بغض النظر عن المنصة وبالتأكيد يؤدي إلى نمط تنمية أكثر اتساقا.

Answer 19

IMHO إنها مسألة عادة.أيًا كان ما اعتدت عليه سيبدو طبيعيًا وصحيحًا.

يمكنك التوصل إلى الكثير من المبررات التي تفسر لماذا هو جيد أو سيئ، ولكن لا يوجد منها الكثير من الماء.على سبيل المثال:

• يمكنك الحصول على المزيد من المعرفات المحتملة، على سبيل المثال. foo ضد Foo ضد FOO.
• لكن وجود معرفات تختلف فقط في الحالة ليس فكرة جيدة
• يمكنك تشفير معلومات النوع في اسم (على سبيل المثال. FooBar= اسم النوع، fooBar=وظيفة، foo_bar=متغير، FOO_BAR=ماكرو)
• ولكن يمكنك القيام بذلك على أي حال باستخدام التدوين المجري

Answer 20

ولأنه كيف تعمل اللغة الطبيعية أيضا.

Answer 21

في progamming هناك ما يمكن أن يقال عن حساسية القضية، على سبيل المثال وجود الممتلكات العامة فو والخاص / محمية فو الحقل المطابق. مع التحسس انها ليست من الصعب جدا على عدم ارتكاب الأخطاء.

ولكن في نظام التشغيل، وحساسية القضية هي مجرد مجنون. أنا حقا لا أريد أن يكون لديك ملف فو <م> و فو <م> و فو في نفس الدليل. هذا يدفعني كراي في كل أفعله الاشياء * لا شىء.

Answer 22

وبالنسبة لي حساسية القضية هي مجرد مسرحية على نطاقات مثل thisValue للحجة وThisValue لممتلكات عامة أو وظيفة.

وأكثر من المرات التي تحتاج إلى استخدام نفس اسم المتغير (كما أنها تمثل نفس الشيء) في نطاقات مختلفة وحساسية القضية يساعدك على القيام بذلك دون اللجوء إلى البادئات.

يا للعجب، على الأقل نحن لم تعد تستخدم تدوين المجرية.

Answer 23

وبعد أن عمل سنوات عديدة مع تراث التعليمات البرمجية VBScript ASP، عندما انتقلنا إلى صافي اخترنا C #، وكان واحدا من الأسباب الرئيسية لحالة حساسية. وكان القانون القديم غير قابل للقراءة لأن الناس لم يتبع أي اتفاقية: كان كود فوضى غير قابل للقراءة (وأيضا، ساعدت ايديس VBSCRIPT الفقيرة على ذلك)

.

في C # يمكننا تحديد اصطلاحات التسمية والجميع يجب أن تتبع لهم. إذا لم يتم فتش شيء بشكل صحيح، يمكنك تسميته (مع إعادة بيع ديون، ولكن هذا ميزة IDE) ولن يكون هناك أي مشكلة لأن فئة أو متغير سيتم تسمية بنفس الطريقة في جميع أنحاء التعليمات البرمجية.

وأخيرا، أعتقد أنه أكثر قابلية للقراءة كثيرا إذا فتش كل شيء بشكل صحيح. ربما هو أسرع لكتابة دون حساسية القضية، ولكن من رمز مراجعة ونقطة الحفاظ ليس أفضل شيء لتخطي خلال التعليمات البرمجية تبحث عن شيء أسهل. على سبيل المثال أسهل للعثور على كافة سلاسل "فو" في لمحة من البحث عن "فو '،' فو '،' فو '،' فو '...

Answer 24

واللغات القضية حساسة لا تعمم بسهولة إلى مجموعات الأحرف غير ASCII. تحويل قضية السليم للغة أخرى غير الإنجليزية ليست مهمة بسيطة، ويعتمد على لغة النظام، من بين أمور أخرى.

Answer 25

وحالة عدم الاكتراث من الصعب جدا، إلا إذا كنت تقييد بناء الجملة إلى أسكي (أو لا تنطبق إلا على حالة عدم الاكتراث لأحرف ASCII)، وأيضا تحتاج إلى تقييد لغة.

والقواعد لتحديد حالة العلوية والسفلية من الشخصيات ويست محددة بشكل جيد، كما أنها ليست ضياع.

وبعض الشخصيات يمكن أن يكون لها أكثر من شكل واحد 'صغيرة'. بعض الناس سوف نختلف حول ما ينبغي أن يكون على شكل الأحرف الكبيرة الصحيح.

و(بعض اللغات والبيئات تسمح للطابع تقريبا ليتم استخدامها في أسماء)

في C # ما هو الفرق بين ToUpper () وToUpperInvariant ()؟