Printable View
قطعا به نظر من باید برنامه نویسان سطح بالاتر مخاطب این گفتگو ها باشند مگر نه گفتگو های سطح پایین رو ادم های دیگه هم میتونن انجام بدننقل قول:
نوشته شده توسط salehbagheri
هدف ایجاد یک سری گفتگو برای روجوع همیشگی به ان برای کسانی که شغلشان برنامه نویسی هست باید باشد
حرف های ساده تر را در تاپیک های ساده تر هم میتوان زد
بحثهاي بي ارتباط رو كجا بايد پست كرد؟
ميخواستم بگم كه اگه اين گفتگوهاي ارزشمند جاي پايي در مجله برنامه نويس داشته باشند فوق العاده ميشه...
حيف هست كه اين مطالب رو به صورت آفلاين نداشته باشيم.
آفلاين كمه بايد اين مطالب رو رو سنگ نوشت ...
با سلام
جناب مداح در صورت امکان طریق تست کردن کد ها (Unit Test) را در برنامه نویسی با ASP.NET MVC را توضیح دهید
با تشکر
جمله آخر بسيار زيبا بود ، اگر جسارت بنده را بپذيريد چند مطلبي را اضافه مي كنمنقل قول:
نوشته شده توسط Behrouz_Rad
يكي از كاربردهاي inteface وراثت چند گانه است ، آيا تا به حال به اين مورد برخورد كرده ايد كه يك كلاس چگونه مي تواند از دو كلاس بطور همزمان ارث ببرد .در اينجا برخي از خصوصيات inteface , و كلاس abstract را بطور خلاصه بيان مي كنم ، به نظرم در اين مورد تايپيك جدا گانه اي لازم داره
خصوصيات اينترفيس
1-كاربرد در بحث وراثت چندگانه
2-اينترفيس نمي تواند عملي را انجام دهد و صرفا يك چارچوب و قاعده براي كلاسها تعريف مي كند
3-سطح دسترسي توابع و متدهاي آن تابع سطح دسترسي خود اينترفيس است
اما كلاس abstract
1-فقط مي تواند يك كلاس آن را به ارث ببرد
2-توابع و متدهاي آن مي توانند عملياتي را انجام دهند
3-توابع و متدهاي آن مي توانند سطح دسترسي داشته باشند
و .........
اما در بحث كد نويسي به نظر من داشتن يك ديكشنري براي متغيرها بسيار ضروري است ، مثلا ممكن است در چند جا شما متغيري همنام استفاده كنيد كه باعث گيجي مي شود
به نظر من قبل از آغاز كار يك قاعده براي نام گذاري قرار دهيم و هر متغيري را در ديكشنري ذخيره كنيم به اين ترتيب كه اين متغير يا كلاس و يا تابع و متد در كجا بكار رفته و چه كارهايي را انجام مي دهد تا به هنگام تعريف تابع يا متغير جديد حداقل از همنام بودن جلوگيري شود
نمي دانم تا چه حد توانستم مطلب را برسانم
با تشكر فراوان از استادان بزرگوار
دوست عزیز
طراحی به صورت
Interface >> Common Implementation >> Special Implementation
یکی از روش های خوب طراحیه
سلام ،
اول یه پیشنهاد ، برای تشکر در قسمت بحث دربارۀ گفتگوی فنی پاسخ ارسال نکنیم که تعداد صفحات الکی بالا نره و بشه راحت تر مطالب رو دنبال کرد ، از دکمه تشکر استفاده کنیم .
یه درخواست هم از آقایان موسوی ، مداح و عسگری دارم ، اینکه بعضی کلمات خیلی تخصصی هستن ، من که دو سالی هست با .Net حرفه ایی ! کد می زنم ، تو عمرم همچین اصطلاحاتی نشنیدم !!! اگه می شه آخر متن هایی که می نویسید ترجمه که نه ولی معادل فارسی یا اینکه این اصطلاح یعنی چه رو هم بنویسید ، مثل کتاب ها که برای کلمات سختشون * می ذارن ! :افسرده:
ممنون . :قلب::قلب:
یک چند نفری سهوا اینکار رو کردن که خودشون هم بعد از اینکه متوجه شدند , پاک کردند.نقل قول:
نوشته شده توسط majidmjh
به نظرم که خیلی ساده و روان توضیح میدند , منتها به نظر من فاصله زمانی بین پستها داره زیاد میشه , که از شکل یک تاپیک داغ فاصله میگیره .نقل قول:
نوشته شده توسط majidmjh
شما میتونی هر اصطلاحی رو که متوجه نشدی اینجا مطرح کنی , اصلا این تاپیک واسه همین جور موارد ایجاد شده .
در این کد آقای موسوی اومدن GetGrandTotal() از کد اصلی جدا کردن ، این کار باعث شده که foreach دوبار توی تکرار بشه ، درسته که خوانایی برنامه بالاتر رفته و بوی بد کد کمتر شده ولی این باعث کند شدن برنامه نمی شه شاید مجبور بشیم این foreach رو صد بار تو برنامه صدا بزنیم ! اون وقت صد بار می خواد محاسبه کنه
بهتر نیست یه foreach باشه و این تابع ها توی اون تکرار بشه ، توی کد های من این اتفاق خیلی افتاده ... ممنون .
public void PrintInvoice()
{
PrintInvoiceHeader();
decimal grandTotal = GetGrandTotal();
PrintInvoiceDetails(grandTotal);
}
private void PrintInvoiceDetails(decimal grandTotal)
{
//Print invoice items and calculate the grand total...
foreach (Item item in this.items)
{
Console.WriteLine("Id: " + item.Id);
Console.WriteLine("Name: " + item.Name);
}
//Print the grand total
Console.WriteLine("Grand Total: " + grandTotal);
}
private decimal GetGrandTotal()
{
decimal result = 0;
foreach (Item item in this.items)
result += item.Price;
return result;
}
private void PrintInvoiceHeader()
{
//Print invoice header...
Console.WriteLine(this.invoiceId);
Console.WriteLine(this.customerName);
}
ویرایش :
ای کاش تا قبل از اینکه برم سربازی اینو جواب می دادید !! چون برام خیلی مهمه ! من سه شنبه صبح باید برم ... :'(
با عرض پوزش از آقای راد، ولی همینطوریش وقتی آقا صالح در مورد اصطلاحات ابهام دارن -یا از طرف بقیه صحبت می کنن-، فکر کنم تعمیم مساله حتی در این حد هم درست نباشه؛ صورت مساله Refactoring بود که آقای موسوی تمام تلاششون رو کردن تا با ساده ترین و در عین حال درست ترین زبان بیانش کنند.نقل قول:
نوشته شده توسط Behrouz_Rad
البته شما استاد امثال بنده هستید ولی اگه بخواهیم در مورد ماهیت سولوشن صحبت کنیم، فکر کنم حالا حالاها در جا می زنیم :خجالت:؛ مثلاً IMobility هم میتونه IVehicle باشه، اونهم از IObject منشعب بشه و الا ماشا...
"وقتي يك بنده خدا محتواي كد رو نميفهمه از كجا تشخيص بده خوبه يا بد؟ اگه مخاطبان شما افراد حرفه اي هستند كه هيچ! "
آقای باقری، چرا بچه ها رو می ترسونی؟ مگه کدها چه محتوایی دارن که یه برنامه نویس معمولی، متوجه اش نشه؟ فقط اون آخراش آقای موسوی برای اینکه یکم لذت ببرن، یکم سازنده تو سازنده کردن، که هوشمندانه بوده و خوب برحسب تجربه های مکرر و بنظرم بهتره به چشم ما هم بخوره:
" به Class Diagram این کد نگاه کنید و از اون لذت ببرید"
جالب بود.:لبخند:نقل قول:
نوشته شده توسط majidmjh
چه فرقی کرده مگه؟ فقط عوض اینکه همه تو یه تابع زیر هم ردیف بشن، به چند تابع شکسته شدند ولی تو ماهیت کار هیچ فرقی نیست! foreach بازاء هربار فراخوانی تابع GetGrandTotal اجرا میشه و داخل متغیر grandTotal ریخته میشه که اونهم فقط یکبار از تابع PrintInvoice فراخوانی میشه. یعنی در اون حالت که شما میگی: عوض اینکه 100 تا foreach زیر هم بنویسی؛ 100 بار متغیری که تابع مقداردهی کرده رو استفاده میکنی، فقط همین تفاوت هست.نقل قول:
نوشته شده توسط majidmjh
مساله Performance که آقای موسوی در موردش صحبت میکنن، خیلی جزئی تر از اینی هست که شما در موردش صحبت میکنید، بیشتر به روال کامپایل توابع بر میگرده تا عملکرد کد و هیچوقت یک تابع معادل کدهای زیرهم، بیشتر از اون کد بو دار اجرا نمیشه. البته چون موضوع بحث اونجا عوض شده به خودم جسارت توضیح دادم، اساتید میبخشن.
فکر کنم آقای موسوی اونقدر به ریز مسائل توجه شون معطوف شد که حوصله شون سر رفت، بابا دیگه اینهمه هم :گیج: نیستیم :
خدمت متولیان برنامه گفتگوی فنی شماره یک: ما داریم استفاده می کنیم؛ لطفاً ادامه بدین؛ البته مجری هم که فعلاً برنامه رو تعطیل کردن.:لبخندساده:نقل قول:
نوشته شده توسط mehdi.mousavi
من چند تا نکته به ذهنم میرسه:
1) چرا Unit Testing و نیز MVC رو اینقدر خلاصه از روش گذشتید و نظر آقای موسوی رو نپرسیدین، در ضمن مثل اینکه اینا هم مثل مباحث UML هستن، نه؟ یعنی همه درموردشون صحبت میکنن ولی در عمل فقط در سطح همون حرف های قشنگ باقی میمونن! یا فکر کنم من درست توجیه نشدم؛ مثلاً Model، View، Controller و ... رو دیدم و خیلی شبیه UML و DFD و مستندسازی های مراحل هستند که اگه اینطوری باشه، آدم باید تمام پروژه ها رو بخوابونه که از اول همه چیز طراحی بشه؛ واقعاً لازمه که آدم برای آزمایش کد از این روال پیروی کنه؟ بعبارت دیگه همه که برنامه نویس وب یا دیتابیس نیستند و در پروژه های دیگه هم برای Unit Test اِ صحیح، لازمه که از این مباحث استفاده بشه یا روشهای استاندارد و عملی دیگه ای هم هست؟ چون بنده با یک مطالعه کوچک به Event هایی که Delegate ای براشون تعریف نشده و از EventHandler خود دات نت استفاده میکنند یا Singleton Pattern ها و مفاهیم چندریختی و ... توشون استفاده شده که حوصله برنامه نویسان رو شدیداً مورد آزمایش قرار میدن! منظورم اینه که اگه بخواهیم محیط توسعه مون بقول آقای موسوی، Brownfield نباشه ولی برای هر چیز جزئی هم نیاز به اينترفيس IModel و Observer و رویدادهای اطلاع رسانی و ... نداشته باشیم باید چکار کنیم؟ اینا بیشتر توسعه دهنده رو فراری میدن تا ترغیب به تمیزی/نظافت یا بوی خوب کد.
خوب اگه قرار باشه اینهمه پیچیدگی بیاد سمت برنامه نویس، پس صد و خرده ای مگ برای پلت فرم دات نت رو برای چی رو سرورهامون نصب می کنیم؟ با همون ++C/C کدهامونُ می نوشتیم دیگه :لبخند:
2) Divergent Change (تغییر واگرا) و Shotgun Surgery رو میشه بیشتر توضیح بدین؟ من نوعی تو برخی کدهام، فکر میکنم که درست تر از این دیگه نمیشه و از زمان و وقتم هم هزینه میکنم و دنبال کدهای تمیز مشابه و قابل استفاده برای نمونه می گردم و ... ولی باز هم - علیرغم دقت اولیه- طی زمان همچین مشکلاتی شبیه اون چیزی که آقای موسوی فرمودن برام پیش میاد. اینا دیگه Refactoring نیستند که تو توسعه نهایی سیستم تاثیری نداشته باشند؛ باید هزاران خط کد از اول بهینه سازی بشه یا دید توسعه دهندگان سیستم عوض بشه و بردارن تمام اجداد کلاسها رو بهینه نویسی کنند که اونهم معلوم نیست بازم Refused Bequest بشن یا نه! اینا واقعاً تو پروژه هایی که پرونده شون مثلاً بسته شده و تغییرات جزئی میخوان هزینه بر و اعصاب خوردکن هست؛ چه راه حلی پیشنهاد می کنید؟ یا بنظرتون از این به بعد چی کار کنیم بهتره؟
خیلی از به اشتراک گذاشتن تجربیات ارزشمند خودتون تشکر میکنم.
StyleCop صرفا برای #C هست یا برای کدهای VB.Net هم کاربرد داره؟
فقط برای C# هست... البته از "برخی" رهنمون هایی که میده می تونی ایده بگیری و در VB هم پیاده سازی کنی.نقل قول:
نوشته شده توسط naeeme
موفق باشید.
سلام اقا بهروزنقل قول:
نوشته شده توسط Behrouz_Rad
من دلیل بعضی رهنمود هاشو نفهمیدم
مثلا اینکه اسم متغیر با حرف بزرگ شروع نشه یا اکثر مواقع پیشنهاد میده متغیر از نوع var تعریف بشه دلیل این ها چیه؟
ممنون
البته سوال شما مربوط به 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 مورد نظرتان اضافه کنید.
اینها به همون قواعد نامگذاری بر میگرده که برادران موسوی و مداح در مورد برخی از اونها توضیح دادند.نقل قول:
نوشته شده توسط saed2006
استفاده از var رو فقط برای Anonymous Types پیشنهاد می کنم. زمانی که نوع متغیر یا شی ای رو می دونید، از var استفاده نکنید چون باعث کاهش خوانایی برنامه میشه.
موفق باشید.
سلام.نقل قول:
نوشته شده توسط saed2006
ببخشید سوال منحصر به شخص خاصی بود ولی گفتم جواب بدم..
پیشنهاد میکنم 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}
}
قرار نیست گفتگوی بعدی رو شروع کنید ؟
در یک ماه اخیر آقای مداح تنها یک پست در این تاپیک داشتند , فکر نمیکنید اینو تمومش کنید بهتره ؟