7 سبک برنامه نویسی در تاریخ
اگر شما بیش از یک دهه است که کد نویسی می کنید، ممکن است سبک های ترجیحی داشته باشید که کاملاً به آنها اعتقاد داشته باشید و با استدلال های خود کنار بیایید تا آخر از آنها دفاع کنید.
در زیر برخی از آنها ذکر شده است که من یک بار محکم کنار آنها ایستاده ام، اما اکنون فکر می کنم که باید آن را رها کنم.
1- برای نشان دادن متغیرهای عضو از m یا this استفاده کنید.
قانون : برای تمایز کردن متغیرهای عضو از متغیرهای محلی، یکی از موارد زیر استفاده کنید
- استفاده از علامت گذاری mMemberVariable VS localVariable و m مخفف متغیر عضو هست .
- استفاده از this : this.mMemberVariable VS localVariabl
دلیل گذشته
دلیل آن این بود که وقتی کد را می خوانیم، بدون اینکه به اظهارات آنها نگاه کنیم، به راحتی می توانیم بفهمیم که آنها متغیرهای عضو یا متغیرهای محلی هستند.
class MyClass
{
var mMember = "member"
fun doSomething()
{
val local = "local"
println(this.mMember)
println(local)
}
}
اکنون
اگر IDE مدرن باشد، چنین تمایزی بر اساس متن دیگر لازم نیست. همان کد زیر را مشاهده کنید، به طور خودکار آنها را به طور متفاوتی رنگ می کند.
2 – همیشه عمومی یا خصوصی ، محافظت شده تعریف کنید
حالت پیش فرض را فرض نکنید. همه متغیرها و توابع درون یک کلاس باید صریحاً به صورت عمومی، خصوصی یا محافظت شده بیان شوند.
- باید صریحاً نوع آن را بیان کنید مثال Int یا String
- نیاز به صراحت بیان آن است Private یا Public
public class MyClass {
public val publicVariable: String = "100";
private fun privateFunction() {};
public fun publicFunction() {};
}
دلیل گذشته
جلوگیری از دسترسی اشتباه به عملکرد و متغیر ها ، ، به عنوان مثال اگر یک عملکرد اعلام نشده باشد، ممکن است کاربر از حالت پیش فرض در صورت عمومی یا خصوصی بودن آن اطلاع نداشته باشد.
اکنون
با IDE مدرن، نیازی به صریح اعلام پیش فرض نداریم، به عنوان مثال برای کوتلین که عمومی است. کاربران به طور تصادفی حالت پیش فرض را اشتباه نمی گیرند زیرا تکمیل خودکار فقط روش های عمومی را نشان می دهد. بنابراین به احتمال زیاد کسی وضعیت پیش فرض را اشتباه نمی گیرد.
در صورت استفاده اشتباه مثلا دسترسی خصوصی به عملکرد ،در زمان کامپایل خطا نمیده ،بلافاصله یک پیام خطا نمایش میدهد.
3 - همیشه یک نوع متغیر را صریح اعلام کنید
قانون : صریحا نوع همه متغیر ها باید اعلام شود، حتی مقدار دهی شود مثلا رشته یا عدد
publicclass MyClass {
public val publicVariable: String= "100"
private fun privateFunction() {}
public fun publicFunction() {}
}
دلیل گذشته
- این کار برای جلو گیری دسترسی اشتباه به عملکرد یا متغیر هست
- وقتی نوع متغیر اشتباه تعریف شود باعث ایجاد خطای کامپایل می شود.
حال
در زبان های برنامه نویسی مدرن، نیازی به بیان صریح نوع متغیر نیست اگر قابل تغییر و بدون ابهام باشد. به این استنباط نوع می گویند. امروزه به بسیاری از زبانهای مدرن موجود است.
اگر تکالیفی اشتباه و غیره وجود داشته باشد، خطا فقط در زمان کامپایل رخ نمی دهد. بلافاصله یک پیام خطا می دهد.
4 - متغیر عضو باید همیشه خصوصی باشد
قانون: همه متغیرهای عضو باید خصوصی باشند و از طریق گیرنده تنظیم و قابل دسترسی باشند، برای متغیرهای عضو باید از خارج تنظیم و اطلاعات دریافت کنند .
public class MyClass{
private var member = "member";
public fun getMember(): String {
return member;
}
public fun setMember(value: String) {
member = value;
}
}
دلیل گذشته
اگر برای تنظیم و دریافت آن را عمومی کنیم، درصورت نیاز به انجام عملیاتی هنگام تنظیم یا دریافت، باید تمام کدی را که به آن دسترسی دارد تغییر دهیم.بنابراین اگر محدود به گیرنده و تنظیم کننده باشیم، کنترل آن را در دست داریم.
class MyClass{
private var member = "member";
fun getMember(): String {
println("Setting member")
return member;
}
fun setMember(value: String) {
println("Setting member with $value")
member = value;
}
}
حال
در زبان های مدرن (مثال کوتلین) ، تفاوت عملکرد در دریافت و ارسال هست ما می توانیم متغیر getter یا setter را در صورت نیاز وارد کنیم بدون اینکه صریحاً دو کارکرد متفاوت داشته باشیم.
بنابراین می توانیم بدون داشتن اطلاعات اضافی برای عملگرد دریافت و ارسال عملکرد کلاس مانند کد زیر استفاده کرد
class MyClass {
var member = "member"
}
در صورتی که لازم است از دریافت یا ارسال انجام شود ،میتوان بدون نیاز به تغییر کد دسترسی متغیر عضو را تغییر داد
class MyClass {
var member = "member"
get(): String {
println("Setting member")
return field
}
set(value: String) {
println("Setting member with $value")
field = value
}
}
5 – شروع و پایان کروشه حلقه ای باید تراز شوند
قانون : همه کروشه های فر باید در یک ستون قرار بگیرند تا بتوانیم جفت آنها را به راحتی پیدا کنیم
class MyClass
{
private var member: String = "member"
fun doSomething(state: Boolean)
{
val local = "local"
println(member)
println(local)
}
}
دلیل گذشته
دلیل آن این بود که با نگاه کردن بصورت عمودی براحتی جفت آن را پیدا کنیم ، از این رو بدانید دامنه عملکرد کجاست.
حال
در IDE های جدید تا زمانی که کد شسته و رفته به نظر برسد، دیگر نیازی نیست که کروشه حلقه ای شروع و پایان را در همان ستون تراز کنیم.
class MyClass {
private var member: String = "member"
fun doSomething(state: Boolean) {
val local = "local" println(member)
println(local)
}
}
دلیل این امر این است که ما می توانیم آنها را به راحتی شکسته یا گسترش دهیم همانطور که در زیر نشان داده شده است.
6- برای تمام تورفتگی از Tab استفاده کنید
قانون : به جای استفاده از فاصله، از Tab برای تمام دندانه استفاده کنید
دلیل گذاشته
تعداد تایپ تکراری را کاهش می دهد مثال هنگام استفاده از فضا نشان داده شده باید بارها تایپ کنید
حال
در IDE های جدید ، تعداد فضای مناسب برای ما تورفتگی خواهد داشت.همچنین داشتن فضاها باعث می شود که همه کدها در محیط کاربران سازگار باشند.
7 - استفاده از نقطه ویرگول برای پایان دادن کد ها
قانون : هنگام پایان دادن به یک عبارت کد، یک نقطه ویرگول مورد نیاز است.
در زبان های برنامه نویسی از زمان های قدیم الزامی است c یا c++ وjava و etc تا تجزیه کننده تشخیص دهد که پایان یافته است.تا حدی به این دلیل که ما 80 ستون داریم و از این رو نیاز به کدگذاری بیشتر برای یک عبارت است ، ما می توانیم در چندین خط برای یک عبارت کدگذاری کنیم.
حال
در زبان های مدرن مثل کاتلین ، دیگر نیازی به رمزگذاری یک عبارت طولانی ترن نیست (به عنوان مثال می توان متغیر را تورفتگی های کوتاهتر و کوتاهتر نام برد).حتی اگر نیاز به رمزگذاری عبارات طولانی تری داشته باشیم، دیگر مجبور به 8 ستون نخواهیم بود (اگرچه عمل خوبی نیست)علاوه بر این، مانیتور ما این روزها طولانی تر است ...
بنابراین اگر زبانی اجازه استفاده از نقطه ویرگول را نمی دهد، دنبال آن بروید!
7 سبک کدگذاری در بالا اعتقاد من تغییر داد ، من کد های خودم را مانند زیر تغییر داده ام
جهان همیشه در حال تغییر است، آنچه در گذشته مورد نیاز است ممکن است دیگر مربوط نباشد، با استفاده از فناوری و ابزار، ما همیشه باید قوانینی را که قبلاً داشته ایم دوباره ارزیابی کنیم. و پیشرفت کنیم.
خیلی جوانتر احساس کنید. ببینید چطور حرفه کدگذاری تغییر کرده است!
مطلبی دیگر از این انتشارات
7 توصیه مهم کوئری نویسی در SQL Server
مطلبی دیگر از این انتشارات
آشنایی با معایب و مزایای ری اکت نیتیو و فلاتر برای برنامه نویسی اندروید
مطلبی دیگر از این انتشارات
برای use case نوشتن باید چکرد؟