StyleCop صرفا برای #C هست یا برای کدهای VB.Net هم کاربرد داره؟
Printable View
StyleCop صرفا برای #C هست یا برای کدهای VB.Net هم کاربرد داره؟
البته سوال شما مربوط به Visual Studio هست، و در این بحث هم مثال های ارائه شده مربوط به #C و Visual Studio 2010 هستند؛ اما اگر دوستانی از سایر IDEها استفاده می کنند، می تونند معمولا امکانات مشابه قابلیت های مطرح شده در این تاپیک را در IDEهای مورد استفاده خودشان هم پیدا کنند.نقل قول:
StyleCop صرفا برای C# هست یا برای کدهای VB.Net هم کاربرد داره؟
به عنوان نمونه؛ دوستانی که از RAD Studio (برای دلفی و C++ Builder) استفاده می کنند، می تونند با استفاده از گزینه Refactoring، در Context menu مربوط به Code Editor، یا استفاده از منوی Refactor، عمل Refactoring را انجام بدند:
ضمیمه 51625
برای قابلیتی مشابه StyleCop، هم می تونند از منوی Project گزینه QA Audits را انتخاب کنند، و برای این کار نیاز به نصب ابزار جانبی نیست:
ضمیمه 51626
در IDEهای دیگه هم ممکنه بتونید این قابلیت ها را پیدا کنید، یا با استفاده از ابزارهای جانبی، این قابلیت ها را به IDE مورد نظرتان اضافه کنید.
سلام.
ببخشید سوال منحصر به شخص خاصی بود ولی گفتم جواب بدم..
پیشنهاد میکنم Documentation این ابزار رو هم دانلود کنید که دلیل وجود چنین قوانینی رو در اون کاملا توضیح داده.
مثلا برای همین سوال که اسم متغیر با حروف بزرگ نمایش داده نشه این جواب رو داره:
نقل قول:
A violation of this rule occurs when the name of a field or variable begins with an upper-case letter. Field and variable names must begin with a lower-case letter, unless the field is public or internal, const, or non-private and readonly. In these cases, the field should begin with an upper-case letter.
If the field or variable name is intended to match the name of an item associated with Win32 or COM, and thus needs to begin with an upper-case letter, place the field or variable within a special NativeMethods class. A NativeMethods class is any class which contains a name ending in NativeMethods, and is intended as a placeholder for Win32 or COM wrappers. StyleCop will ignore this violation if the item is placed within a NativeMethods class.
Design Guidelines for Developing Class Libraries عنوان مجموعه ای هست که بعضی از قسمتهای اون تقریبا مرتب با موضوعات تاپیک هست که خوندنش قطعا مفید خواهد بود . به گفته خودشون :
نقل قول:
It is strongly recommended that you follow these design guidelines when developing classes and components that extend the .NET Framework. Inconsistent library design adversely affects developer productivity and discourages adoption.
Guidelines for NamesDescribes guidelines for naming types and members in class libraries.
Type Design GuidelinesDescribes guidelines for using static and abstract classes, interfaces, enumerations, and structures.
Member Design GuidelinesDescribes guidelines for designing and using properties, methods, constructors, fields, events, and operators. This section also describes best practices for designing parameters.
Designing for ExtensibilityDescribes guidelines for designing libraries that can be extended.
Design Guidelines for ExceptionsDescribes design guidelines for designing, throwing, and catching exceptions.
Usage GuidelinesDescribes guidelines for using arrays and attributes, and guidelines for implementing equality operators.
Internal Coding Guidelines هم مقاله ای هست که به صورت خلاصه مواردی دیگری رو پیشنهاد میکنه .
یک سوال کوتاه:
قشنگتره که پراپرتی های کلاس رو کجای ادیتور بنویسیم؟
یعنی ترتیب تعاریف اجزا، مثلا:
اول سازنده
بعد پراپرتی ها
بعد متدها
----یا
اول پراپ ها
بعد سازنده
بعد متد ها
آخر سر هم مخرب کلاس و...
کدوم یکیش؟
اینطوری خوبه؟
:بوس:
calss x
{
constructor(){}
props;
methodes(){}
~destructor(){if needed}
}
قرار نیست گفتگوی بعدی رو شروع کنید ؟
در یک ماه اخیر آقای مداح تنها یک پست در این تاپیک داشتند , فکر نمیکنید اینو تمومش کنید بهتره ؟