يجب أن تعرف مشغل الأسبقية بدقة ؟

Question

يجب على المبرمج أن يكون على بينة من مشغل الأسبقية بدقة ؟ استخدام الأقواس لتجميع التعبير ينبغي أن تكون بخير, أليس كذلك ؟ أنا دائما يستخدم الأقواس على الجانب أكثر أمانا.وعندما طرح السؤال على الأسبقية ، لا أستطيع الإجابة بسهولة.

Answer 1

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

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

int x = (y << shift) + offset;

أو

int x = y << (shift + offset);

Answer 2

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

Answer 3

قبل سنوات رأيت هذه الأسبقية طاولة C:

• والقسمة يحدث قبل الجمع والطرح.
• استخدام الأقواس.

هذا هو قليلا أكثر مبسطة ، ولكن لديها فكرة الحق.

Answer 4

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

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

Answer 5

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

Answer 6

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

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

Answer 7

وبالتأكيد لا يمكن أن يصب، ويمكن أن تساعدك على قراءة رمز مع الدقيقة precendence مكتوبة من قبل الآخرين.

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

Answer 8

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

وقال مع ذلك، يجب أن نعرف أين للبحث عن معلومات على الأسبقية المشغل، في حال كنت الحفاظ على كود الآخرين.

Answer 9

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

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

Answer 10

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

وأنا لا أعتقد "دائما الأقواس" هو قاعدة جيدة من التجربة. التعليمات البرمجية التي لديها عدد كبير جدا من أقواس يحصل من الصعب قراءة من اللازم. مثل:

(a * b) + c

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

Answer 11

سريعة, التي لديها أعلى الأسبقية في T-SQL:و مقابل أو.

SELECT c.Name
FROM [Customer] c LEFT JOIN [Order] o
  ON c.CustomerKey = o.CustomerId
WHERE c.Name like 'B%'
  OR c.Name like 'Z%'
  AND o.CustomerId is NULL

ذات مرة كنت تعلم الأسبقية من هذه الشركات إلى نقطة لك تعتمد على الأسبقية, أنت محكوم إما إلى:

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

Answer 12

وأعتقد أنه من المهم أن نفهم قواعد predidence الأساسية. أجد معرفة التفاصيل نيتي] رملية أن يكون لا يستحق الوقت. ويرجع ذلك أساسا أي حال predecence غامضة يمكن حلها مع مجموعة بسيطة من أقواس. ثانيا لأن ليس كل من يعرفهم وأنه من الأفضل لجعل التعليمات البرمجية للقراءة للمستخدمين في مجموعتك.

وفي وقت واحد في الكلية، وكنت أعرف كل قواعد predence عن ظهر قلب. مرة واحدة حصلت في العالم الحقيقي وجدت معظم الناس لم نعرفهم عن ظهر قلب. إذا راجعت بعض رمز صالح التي تعتمد عليها بعض القواعد predecence حصلت باستمرار ردود الفعل نفسه "إضافة أقواس لجعلها واضحة".

Answer 13

وهناك خيار ثالث. بدلا من حفظ كل تلك القواعد، <م> أو استخدام الأقواس للتأكد من كل شيء ...

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

Answer 14

لا

إذا كنت غير متأكد من الأسبقية ثم في المحتمل ان أي شخص آخر في قراءة رمز سيكون عرضة للتفسير بشكل خاطئ.

إذا كنت غير متأكد تماما

 ( .. ) 

البتات relevent عن من التعليمات البرمجية ثم لا يوجد أي غموض بالنسبة لك أو أي شخص آخر.

Answer 15

لم يكون 100% قبضة على الأسبقية قواعد لأنني أعمل في عدة لغات (C, C++, perl, باش, وكل مرة واحدة في حين اندفاعة من TCL/TK.).في أوقات مختلفة على مر السنين لقد عملت مع العديد من مختلف الجمعية لغات غير مطابقة مترجم أو اثنين.

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

Answer 16

نعم:

• * / + -
• && || و أو

لا/ربما:

• << >> & | ^

Answer 17

ومن السهل جدا جدا لخداع نفسك عند كتابة a == a & some_flag.

وحتى لو أود أن أقترح <م> لا تعلم قواعد الأسبقية، وذلك باستخدام الأقواس والمؤقتة المتقبلة لوضوح (تذكر: هو المقصود الرمز إلى قراءتها من قبل البشر )، وأحيانا عامل يأتي الجدول الأسبقية في متناول اليدين.

Answer 18

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

... باستثناء الحس السليم: وكما أشير إلى ذلك، تعابير مثل a * b + c يمكن فهم استخدام المعرفة من دروس الرياضيات. التعبيرات المنطقية مثل a < 4 && a > 0 يمكن أن يفهم لأنه أكثر منطقية أن يكون مقارنات ربط أكثر إحكاما من &&.

وعلى الجانب الآخر، هناك لا معنى مشترك لخلط مشغلي المختصة بالبت مع الحساب العادي، واستخدام أفضل حتى الأقواس هناك. لا توجد أيضا أي الحس السليم لأسبقية && على || (أو كان العكس؟)، هكذا أيضا استخدام الأقواس هناك.