در ادامه تصمیم اخیرم درجهت نوشتن برداشتهای شخصی خود در مورد کد تمیز سومین پست این سری مجموعه رو با نام نامگذاری-قسمت دوم شروع میکنم.
یکی از چالشهایی که در بیشتر تیمهای نرم افزاری با آن روبرو بوده ام، مشکل نام گذاری کلاسها بوده و هست.اگر پست قبلی رو مطالعه کرده باشید، این نکته را به خاطر میآورید که یکی از نکات مهم در نامگذاری انتخاب نامی قابل پیشبینی است.نامهای انتخابی برای کلاسها معمولا شامل اسمها می باشند.نامهای کلاسها می بایست توصیف فعالیت کلاس را انجام دهند.همین اصل ساده به شما کمک به سزایی در رعایت اصلی Single Responsibility در S.O.L.I.D برای شما ایفا خواهد کرد.برای مثال اگر شما نام یک کلاس UserManager را انتخاب کرده باشید، احتمالا فقط فعالیتهای مربوط به مدیریت کاربر را در این کلاس قرار خواهید داد ( البته احتمالا !).
نکته ای که در انتخاب نام کلاسها مهم می باشد، انتخاب نامهایی با سطح انتزاع یکسان ( Abstraction Level ) برای کلاسهای هم سطح می باشد.بدین معنی که زمانی که نام یک کلاس File انتخاب می شود.نام کلاس دیگری که با این کلاس در سطح انتزاع یکسانی است احتملا می بایست Directory باشد و نه UserManager !
هر کلاس شامل چند خصوصیت است.خصوصیتها به صورت عمومی قابل دسترس هستند، پس می بایست مربوط به والد خود باشند.این بدین معنی است که اگر در کلاس Person در حال توسعه هستید، یک خصوصیت می تواند نام فرد باشد.
یکی از مهمترین بخشها در نامگذاری، متدهاست، متدها میبایست فعلهایی در زمینه کاری کلاس والد باشند.برای مثال کلاس File را در نظر بگیرید.متدهای داخل این کلاس می توانند :
باشند.نکاتی در مورد این متدها وجود دارند که توجه شما را به آنها جلب میکنم :
متدها میبایست قابل پیشبینی و همچنین در یک سطح انتزاع از سایر برادران خود باشد.به مثال بالا توجه کنید، تمام متدها در یک سطح از Abstraction هستند و هیچ متدی مانند SaveToDatabase در بین آنها وجود ندارد.
نکته مهم دیگر در نامگذاری توابع انتخاب نامهایی است که گویای ورودی آنها باشد.برای مثال متد WriteFile احتمالا دو ورودی FilePath و FileContent را به عنوان ورودی دریافت میکند.
یکی از شاید مظلوم ترین بخش ها در نامگذاری که معمولا به آنها توجه لازم انجام نمیشود، انتخاب نام مناسب برای ورودی توابع و یا Argument ها میباشد.در بیشتر منابع، ورودی توابع را در سطح متغیرهای محلی در نظر میگیرند-که خیلی هم غیر منطقی نمیباشد- ولی نکته مهم، انتخاب اسمی گویا میباشد.یکی از اهداف اصلی کد تمیز، کد قابل پیش بینی میباشد، انتخاب نام های مناسب برای ورودی توابع منجر به این میشود که توسعه دهندههای دیگر بدون رجوع به داخل تابع، درک درستی از نحوه کار تابع شما داشته باشند.
البته بحث مفصلی در کتاب Clean-Code در رابطه با انواع ورودی های توابع و نحوه کنترل آنها وجود دارد که مطالعه آن را پیشنهاد میکنم.
برای متغیر های محلی نکته قابل اهمیت انتخاب نام هایی است که در Scope متد قابل درک باشند.برای مثال در متد CreateFile یک متغیر احتمالی، normilizedPathForCreatingFile می باشد.این متغیر کار نگهداری آدرس Normal شده فایلی که قرار است ساخته شود را نگهداری میکند.در متغییر های محل طولانی شدن نام متغیر نباید شما را نگران کند، البته طولانی شدنی که نیاز به آن وجود داشته باشد نه فقط به دلیل علاقه شخصی.هدف خوانایی بیشتر در طول مدت است.پس نگران نباشید !
نام گذاری اولین قدم در توسعه کد تمیز است ولی به قول arlobelshee نام گذاری یک پروسه است تا یک قدم از توسعه کار.پیشنهاد میکنم در کنار تمام کتابهای موجود این سری مطلب از وبلاگ arlobelshee را نیز مطالعه کنید، همچنین مطمعا باشید که باز هم نظرات جذابی برای مطالعه وجود خواهد داشت.