ضابطہ اخلاق: مناسب نام رکھنے کی طاقت، اچھے اور برے تبصرے۔

آپ کو کتنی بار کسی اور کے کوڈ کو سمجھنا پڑا ہے؟ جب، چند گھنٹوں کے بجائے، آپ صرف اس بات کی منطق کو سمجھنے کے لیے دن گزارتے ہیں کہ کیا ہو رہا ہے۔ مزے کی بات یہ ہے کہ جس شخص نے یہ کوڈ لکھا ہے اس کے لیے سب کچھ صاف اور شفاف ہے۔ اور یہ حیرت کی بات نہیں ہے: سب کے بعد، کامل یا مثالی کوڈ ایک بہت ہی مبہم تصور ہے، کیونکہ ہر ڈویلپر کا بالترتیب دنیا اور کوڈ کے بارے میں اپنا نظریہ ہوتا ہے۔ ایک سے زیادہ بار میں نے ایسی صورتحال کا سامنا کیا جہاں میں اور میرے ساتھی نے ایک ہی کوڈ کو دیکھا اور اس کی درستگی اور صفائی کے بارے میں مختلف رائے رکھتے تھے۔ یہ ایک واقف احساس ہے، ہے نا؟ تاہم، کچھ وقتی آزمائشی نکات ہیں جن پر عمل کرنا چاہیے، جو بالآخر ہمارے فائدے میں کام کریں گے، کیونکہ اگر آپ اپنے کوڈ کو اس حالت میں چھوڑ دیتے ہیں جس میں آپ خود اسے حاصل کرنا چاہتے ہیں، تو دنیا تھوڑی خوش ہو جائے گی اور کلینر کوڈ لکھنے کے قواعد کے بارے میں اپنے آخری مضمون میں (یا اس کے بجائے، ایک چھوٹا سا گائیڈ)، ہم نے نظام کو مجموعی طور پر لکھنے اور اس کے عناصر جیسے آبجیکٹ، ان کے انٹرفیس، کلاسز، طریقے اور متغیرات پر تھوڑا سا چھوا۔ وہاں میں نے مختصراً بعض عناصر کے درست ناموں کا ذکر کیا۔ آج میں بالکل اسی کے بارے میں بات کرنا چاہوں گا، کیونکہ درست نام کوڈ کو پڑھنے کی اہلیت کو بہت آسان بنا دیتے ہیں۔ ہم کوڈ میں عکاسیوں اور تبصروں کی چھوٹی مثالوں کی مدد سے درست کوڈ کے عنوان کو بند کریں گے - کیا یہ اچھا ہے یا اتنا اچھا نہیں ہے۔ تو آئیے شروع کرتے ہیں۔

درست نام رکھنا

درست نام کوڈ کی پڑھنے کی اہلیت کو بہتر بناتے ہیں، اس کے مطابق واقفیت پر وقت کی بچت ہوتی ہے، کیونکہ جب نام اس کی فعالیت کو تقریباً بیان کرتا ہے تو طریقہ استعمال کرنا بہت آسان ہوتا ہے۔ چونکہ کوڈ میں ہر چیز ناموں (متغیرات، طریقے، کلاسز، فائل آبجیکٹ وغیرہ) پر مشتمل ہوتی ہے، اس لیے درست، صاف کوڈ بناتے وقت یہ نکتہ بہت اہم ہو جاتا ہے۔ مندرجہ بالا کی بنیاد پر، نام کا مطلب یہ ہونا چاہیے کہ کیوں، مثال کے طور پر، ایک متغیر موجود ہے، یہ کیا کرتا ہے اور اسے کیسے استعمال کیا جاتا ہے۔ میں بار بار نوٹ کروں گا کہ متغیر کو بیان کرنے کے لیے بہترین تبصرہ اس کا صحیح نام ہے۔

نام دینے والے انٹرفیس

انٹرفیس عام طور پر ایسے نام استعمال کرتے ہیں جو بڑے حرف سے شروع ہوتے ہیں اور اونٹ کیس (کیمل کیس) میں لکھے جاتے ہیں۔ انٹرفیس لکھتے وقت یہ اچھی مشق ہوتی تھی کہ اسے ایک انٹرفیس (جیسے IUserService) کے طور پر نامزد کرنے کے لیے اسے I کے ساتھ سابقہ ​​لگانا، لیکن یہ کافی بدصورت اور پریشان کن ہے۔ ایسی صورتوں میں، بہتر ہے کہ اس کے بغیر (UserService) لکھیں، اور اس کے نفاذ میں -Impl (UserServiceImpl) کو شامل کریں۔ ٹھیک ہے، یا آخری حربے کے طور پر، اس کے نفاذ میں سابقہ ​​C (CUserService) شامل کریں۔

کلاس کے نام

بالکل انٹرفیس کی طرح، نام بڑے بڑے ہوتے ہیں اور اونٹ سٹائل (کیمل کیس) استعمال کرتے ہیں۔ اس بات سے کوئی فرق نہیں پڑتا ہے کہ کس طرح کی apocalyps ہو رہی ہے، اس سے کوئی فرق نہیں پڑتا ہے کہ آخری تاریخ کتنی تیز ہے، لیکن کبھی نہیں، یاد رکھیں، کلاس کا نام کبھی بھی فعل نہیں ہونا چاہئے! کلاس اور آبجیکٹ کے نام اسم اور ان کے مجموعے ہونے چاہئیں (UserController، User Details، UserAccount، وغیرہ)۔ آپ کو اس ایپلی کیشن کے مخفف کے ساتھ ہر کلاس کا نام فراہم نہیں کرنا چاہیے، کیونکہ اس سے صرف غیر ضروری پیچیدگی پیدا ہوگی (مثال کے طور پر، ہمارے پاس یوزر ڈیٹا مائیگریشن ایپلی کیشن ہے، اور ہم ہر کلاس میں ایک UDM شامل کریں گے - UDMUserDeatils، UDMUserAccount، UDMUserController )۔

طریقوں کے نام

عام طور پر طریقوں کے نام ایک چھوٹے حرف سے شروع ہوتے ہیں لیکن ان میں اونٹ کا انداز (کیمل کیس) بھی استعمال ہوتا ہے۔ اوپر ہم نے اس حقیقت کے بارے میں بات کی کہ کلاس کے نام کبھی بھی فعل نہیں ہونے چاہئیں۔ یہاں صورت حال متضاد طور پر برعکس ہے: طریقوں کے نام فعل یا فعل کے ساتھ ان کا مجموعہ ہونا چاہیے: findUserById، findAllUsers، createUser، وغیرہ۔ کوئی طریقہ بناتے وقت (نیز متغیرات اور کلاسز)، الجھن سے بچنے کے لیے، نام دینے کا ایک طریقہ استعمال کریں۔ مثال کے طور پر، کسی صارف کو تلاش کرنے کے لیے، طریقہ کو getUserById یا findUserById کے طور پر لکھا جا سکتا ہے۔ اور ایک بات: طریقوں کے ناموں پر مزاح کا استعمال نہ کریں، کیونکہ وہ مذاق کو نہیں سمجھ سکتے، اور ساتھ ہی یہ طریقہ کیا کرتا ہے۔

متغیر نام

زیادہ تر معاملات میں، متغیر کے نام چھوٹے حروف سے شروع ہوتے ہیں اور کیمل کیس بھی استعمال کرتے ہیں، سوائے ان صورتوں کے جہاں متغیر عالمی مستقل ہو۔ ایسی صورتوں میں، نام کے تمام حروف بڑے حروف میں لکھے جاتے ہیں اور الفاظ کو ایک انڈر سکور - "_" سے الگ کیا جاتا ہے۔ متغیرات کا نام لیتے وقت، آپ سہولت کے لیے معنی خیز سیاق و سباق استعمال کر سکتے ہیں۔ دوسرے لفظوں میں، جب کسی بڑی چیز کے حصے کے طور پر کوئی متغیر ہو - مثال کے طور پر، firstName، lastName، status - ایسی صورتوں میں آپ ایک سابقہ ​​شامل کر سکتے ہیں جو اس چیز کی نشاندہی کرتا ہے جس کا یہ متغیر حصہ ہے۔ مثال کے طور پر: userFirstName، userLastName، user Status۔ آپ کو متغیرات کے لیے ملتے جلتے ناموں کے استعمال سے بھی گریز کرنے کی ضرورت ہے جب ان کے معنی بالکل مختلف ہوں۔ متغیرات کے لیے عام متضاد الفاظ:

• شروع/ختم
• پہلا آخری
• مقفل/غیر مقفل
• کم از کم/زیادہ سے زیادہ
• اگلا/پچھلا
• پرانا/نیا
• کھلا/بند
• مرئی/غیر مرئی
• ذریعہ/ہدف
• ذریعہ/منزل
• اوپر نیچے

مختصر متغیر نام

جب ہمارے پاس متغیرات ہوتے ہیں جیسے x یا n یا اس طرح کی کوئی چیز، ہم فوری طور پر اس شخص کی نیت نہیں دیکھتے جس نے کوڈ لکھا ہے۔ یہ واضح نہیں ہے کہ n کیا طریقہ کار کرتا ہے: اس کے لیے زیادہ سوچ بچار کی ضرورت ہے (اور یہ وقت، وقت، وقت ہے)۔ مثال کے طور پر، ہمارے پاس ایک فیلڈ ہے - ذمہ دار صارف کی شناخت، اور x یا صرف id جیسے کچھ نام کے بجائے، ہم اس متغیر کو ذمہ دار یوزر آئی ڈی کہیں گے، جو فوری طور پر پڑھنے کی اہلیت اور معنی خیزی کو بڑھاتا ہے۔ تاہم، n جیسے مختصر نام چھوٹے طریقوں میں مقامی تبدیلیوں کے طور پر اپنی جگہ رکھتے ہیں، جہاں اس تبدیلی کے ساتھ کوڈ کا بلاک صرف کوڈ کی چند سطروں کا ہوتا ہے، اور طریقہ کا نام بالکل بیان کرتا ہے کہ وہاں کیا ہوتا ہے۔ ایک ڈویلپر، ایسے متغیر کو دیکھ کر، اس کی ثانوی اہمیت اور بہت محدود دائرہ کار کو سمجھتا ہے۔ نتیجے کے طور پر، متغیر نام کی لمبائی پر کچھ انحصار ہوتا ہے: یہ جتنا لمبا ہوتا ہے، متغیر اتنا ہی عالمی ہوتا ہے اور اس کے برعکس۔ مثال کے طور پر، تاریخ کے لحاظ سے آخری محفوظ شدہ صارف کو تلاش کرنے کا طریقہ:

public User findLastUser() {
   return findAllUsers().stream()
           .sorted((x, y) -> -x.getCreatedDate().compareTo(y.getCreatedDate()))
           .findFirst()
           .orElseThrow(() -> new ResourceNotFoundException("Any user doesn't exist "));
}

یہاں ہم سٹریم کی ترتیب کو ترتیب دینے کے لیے مختصر نام x اور y استعمال کرتے ہیں، اور ان کے بارے میں بھول جاتے ہیں۔

بہترین لمبائی

آئیے نام کی طوالت کے موضوع کو جاری رکھیں۔ نام کی بہترین لمبائی MaxNumberOfUsersInTheCurrentGroup نام کی لمبائی اور n کے درمیان کہیں ہے۔ یعنی بہت چھوٹے لوگ معنی کی کمی کا شکار ہوتے ہیں، اور بہت لمبے والے پروگرام کو پڑھنے کی اہلیت میں اضافہ کیے بغیر پھیلاتے ہیں، اور وہ ہر بار لکھنے میں بہت سست ہوتے ہیں۔ مذکورہ معاملے کو مدنظر نہ رکھتے ہوئے، n جیسے مختصر نام والے متغیرات کے لیے، آپ کو لمبائی تقریباً 8 -16 حروف تک رکھنے کی ضرورت ہے۔ یہ کوئی سخت قاعدہ نہیں ہے: زیادہ رہنما خطوط۔

چھوٹے اختلافات

میں ناموں میں لطیف فرق کو نظر انداز نہیں کر سکتا، کیونکہ یہ بھی ایک برا عمل ہے، کیونکہ آپ محض ناموں میں معمولی فرق کو دیکھ کر الجھ سکتے ہیں یا بہت زیادہ وقت صرف کر سکتے ہیں۔ مثال کے طور پر، InvalidDataAccessApiUsageException اور InvalidDataAccessResourceUsageException کے درمیان فرق کو ایک نظر میں دیکھنا مشکل ہے۔ اس کے علاوہ، چھوٹے L اور O استعمال کرتے وقت اکثر غلط معلومات پیدا ہو سکتی ہیں، کیونکہ وہ آسانی سے 1 اور 0 کے ساتھ الجھ سکتے ہیں: کچھ فونٹس میں فرق زیادہ واضح ہوتا ہے، دوسروں میں کم۔

معنوی حصہ

ہمیں ناموں میں سیمنٹک حصہ ڈالنے کی ضرورت ہے، لیکن مترادفات کے ساتھ اوور پلے نہیں، کیونکہ، مثال کے طور پر، UserData اور UserInfo کا اصل میں ایک ہی مطلب ہے، اور ہمیں یہ سمجھنے کے لیے کوڈ میں تھوڑا گہرائی تک کھودنا پڑے گا کہ ہمیں کس مخصوص چیز کی ضرورت ہے۔ . غیر معلوماتی الفاظ سے پرہیز کریں، مثال کے طور پر، firstNameString: ہمیں لفظ سٹرنگ کی ضرورت کیوں ہے؟ کیا نام تاریخ کی قسم کا ہو سکتا ہے؟ بالکل نہیں: لہذا، صرف - firstName. مثال کے طور پر، میں بولین متغیرات کا ذکر کرنا چاہوں گا، مثال کے طور پر، flagDelete. جھنڈا لفظ کوئی معنوی معنی نہیں رکھتا۔ اسے - isDelete کہنا زیادہ معقول ہوتا۔

ڈس انفارمیشن

میں غلط نام کے بارے میں بھی چند الفاظ کہنا چاہوں گا۔ ہم کہتے ہیں کہ ہمارے پاس userActivityList کا نام ہے، اور جس چیز کا نام دیا گیا ہے وہ List قسم کا نہیں ہے، بلکہ اسٹوریج کے لیے کوئی دوسرا کنٹینر یا کسٹم آبجیکٹ ہے۔ یہ اوسط پروگرامر کو الجھا سکتا ہے: بہتر ہو گا کہ اسے یوزر ایکٹیویٹی گروپ یا یوزر ایکٹیویٹی جیسی کوئی چیز کہا جائے۔

تلاش کریں۔

مختصر اور سادہ ناموں کا ایک نقصان یہ ہے کہ ان کو کوڈ کی ایک بڑی مقدار میں تلاش کرنا مشکل ہے، کیونکہ کیا تلاش کرنا آسان ہوگا: نام یا NAME_FOR_DEFAULT_USER نامی ایک متغیر؟ بالکل، دوسرا آپشن۔ ناموں میں کثرت سے آنے والے الفاظ (حروف) سے بچنا ضروری ہے، کیونکہ اس سے تلاش کے دوران ملنے والی فائلوں کی تعداد میں اضافہ ہی ہوگا، جو کہ اچھا نہیں ہے۔ ہم آپ کو یاد دلانا چاہیں گے کہ پروگرامرز کوڈ کو لکھنے کے بجائے پڑھنے میں زیادہ وقت صرف کرتے ہیں، اس لیے اپنی درخواست کے عناصر کے نام کا خیال رکھیں۔ لیکن کیا ہوگا اگر آپ اسے کامیابی کے ساتھ نام دینے کا انتظام نہیں کرتے ہیں؟ اگر کسی طریقہ کا نام اس کی فعالیت کو اچھی طرح سے بیان نہیں کرتا ہے تو کیا ہوگا؟ یہ وہ جگہ ہے جہاں یہ کھیل میں آتا ہے، ہمارا اگلا آئٹم تبصرے ہے۔

تبصرے

متعلقہ تبصرے کی طرح کچھ بھی نہیں ہے، لیکن کوئی بھی چیز بے معنی، فرسودہ، یا گمراہ کن تبصروں جیسے ماڈیول کو بے ترتیبی نہیں بناتی ہے۔ یہ دو دھاری تلوار ہے، ہے نا؟ پھر بھی، آپ کو تبصروں کو ایک غیر واضح اچھائی کے طور پر نہیں لینا چاہئے: بلکہ، ایک کم برائی کے طور پر۔ سب کے بعد، ایک تبصرہ، اس کے جوہر میں، کوڈ میں ایک ناکام اظہار خیال کے لئے معاوضہ ہے. مثال کے طور پر، اگر یہ بہت مبہم نکلے تو ہم ان کا استعمال کسی نہ کسی طریقے کے جوہر کو بتانے کے لیے کرتے ہیں۔ ایسی صورت حال میں، وضاحتی نوٹ لکھنے کے بجائے کوڈ کو درست طریقے سے ری ایکٹر کرنا بہتر ہے۔ تبصرہ جتنا پرانا ہوگا، اتنا ہی برا، کیونکہ کوڈ بڑھنے اور تیار ہونے کا رجحان رکھتا ہے، لیکن تبصرہ وہی رہ سکتا ہے، اور جتنا آگے جاتا ہے، یہ نوٹ اتنے ہی مشکوک ہوتے جاتے ہیں۔ غلط تبصرے بغیر کسی تبصرے سے کہیں زیادہ خراب ہوتے ہیں، کیونکہ وہ غلط توقعات لگا کر الجھاتے اور دھوکہ دیتے ہیں۔ اور یہاں تک کہ اگر ہمارے پاس ایک بہت ہی مشکل کوڈ ہے، تب بھی اس پر تبصرہ نہیں کرنا، بلکہ اسے دوبارہ لکھنا قابل قدر ہے۔

تبصرے کی اقسام

• قانونی تبصرے وہ تبصرے ہیں جو قانونی وجوہات کی بنا پر ہر سورس کوڈ فائل کے شروع میں چھوڑے جاتے ہیں، جیسے:

  * Copyright (c) 2007, 2013, Oracle and/or its affiliates. All rights reserved.
  * ORACLE PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.

• معلوماتی تبصرے - وہ تبصرے جو کوڈ کی وضاحت فراہم کرتے ہیں (اضافی معلومات فراہم کرنا یا کوڈ کے دیئے گئے حصے کا ارادہ۔

  ایک مثال کے طور:

  /*
  * Объединяет пользователя из бд и пришедшего для обновления
  * Когда в requestUser поле пустое, оно заполняется старыми данными из foundUser
  */
  private User mergeUser(User requestUser, User foundUser) {
         return new User(
         foundUser.getId(),
         requestUser.getFirstName() == null ? requestUser.getFirstName() : foundUser.getFirstName(),
         requestUser.getMiddleName() == null ? requestUser.getMiddleName() : foundUser.getMiddleName(),
         requestUser.getLastName() == null ? requestUser.getLastName() : foundUser.getLastName(),
         requestUser.getAge() == null ? requestUser.getAge() : foundUser.getAge()
         );
         }

  اس صورت میں، آپ تبصرے کے بغیر کر سکتے ہیں، کیونکہ طریقہ کار کا نام اور اس کے دلائل، انتہائی شفاف فعالیت کے ساتھ، خود کو اچھی طرح سے بیان کرتے ہیں۔

• انتباہی تبصرہ - ایک تبصرہ جس کا مقصد دوسرے ڈویلپرز کو کسی کارروائی کے ناپسندیدہ نتائج کے بارے میں خبردار کرنا ہے (مثال کے طور پر، ٹیسٹ کو @Ignore کے بطور کیوں نشان زد کیا گیا):

  // Слишком долго отрабатывает
  // Не запускайте, если не располагаете избытком времени
  @Ignore
  @Test
  public void someIntegrationTest() {
         ……
         }

• TODO - وہ تبصرے جو مستقبل کے لیے نوٹس ہیں جو کرنے کی ضرورت ہو گی، لیکن کسی وجہ سے ابھی نہیں کی جا سکتی۔ یہ ایک اچھا عمل ہے، لیکن بے ترتیبی سے بچنے کے لیے غیر متعلقہ کو ہٹانے کے لیے ان کا اب بھی باقاعدگی سے جائزہ لینے کی ضرورت ہے۔

  Примером послужит:

  //TODO: Add a check for the current user ID (when will be created security context)
  
  @Override
  public Resource downloadFile(File file) {
         return fileManager.download(file);
         }

  Тут мы помечаем, что нужно добавить проверку юзера, который скачивает (id которого мы вытащим из security контекста) с тем, кто сохранил.

• усorвающий комментарий — комментарий, подчеркивающий важность Howого-то обстоятельства, что на первый взгляд может показаться несущественным.

  Как пример, кусочек метода, заполняющий тестовую БД, некими скриптами:

  Stream.of(IOUtils.resourceToString("/fill-scripts/" + x, StandardCharsets.UTF_8)
         .trim()
         .split(";"))
         .forEach(jdbcTemplate::update);
  // Вызов trim() очень важен, убирает возможные пробелы в конце скрипта
  // чтобы при считке и разбивке на отдельные requestы не было пустых

• javaDoc — комментарии, которые описывают API определенного функционала для общего пользования. Наверное, самые полезные комментарии, так How с documentированным API в разы легче работать, но они также могут устаревать, How и любые другие. Поэтому не забываем, что главный вклад в documentацию вносится не комментариями, а хорошим codeом.

  Пример вполне обычного метода обновления пользователя:

  /**
  * Обновляет передаваемые поля для пользователя по id.
  *
  * @param id  id обновляемого пользователя
  * @param user пользователь с заполненными полями для обновления
  * @return обновленный пользователь
  */
         User update(Long id, User user);

Плохие сценарии комментариев

• бормочущий комментарий — комментарии, которые обычно пишут на скорую руку, смысл которых понятен только разработчику, писавшего их, так How только он видит ту ситуацию с теми нюансами, на которые он и ссылается.

  Рассмотрим данный пример:

  public void configureSomeSystem() {
         try{
         String configPath = filesLocation.concat("/").concat(CONFIGURATION_FILE);
         FileInputStream stream = new FileInputStream(configPath);
         }  catch (FileNotFoundException e) {
         //В случае отсутствия конфигурационного file, загружается конфигурация по умолчанию
        }
  }

  Кто загружает эти настройки? Были ли они загружены ранее? Метод предназначен для перехвата исключений и вызова дефолтных настроек? Слишком много вопросов возникает, ответы на которые можно получить лишь углубившись в изучение других частей системы.

• избыточный комментарий — комментарий, который не несёт смысловой нагрузки, так How и так понятно что происходит в заданном участке codeа (он читается не проще, чем code).

  Смотрим пример:

  public class JdbcConnection{
  public class JdbcConnection{
     /**
      * Журнальный компонент, связанный с текущим классом
      */
     private Logger log = Logger.getLogger(JdbcConnection.class.getName());
  
     /**
      * Создаёт и возвращает connection с помощью входящих параметров
      */
     public static Connection buildConnection(String url, String login, String password, String driver) throws Exception {
         Class.forName(driver);
         connection = DriverManager.getConnection(url, login, password);
         log.info("Created connection with db");
         return connection;
     }

  Какой смысл таких комментариев, если мы и так всё прекрасно видим

• недостоверные комментарии — комментарии, не соответствующие истине и лишь вгоняющие в заблуждение (дезинформирующие). Как например:

  /**
  * Вспомогательный метод, закрывает соединение со сканером, если isNotUsing истинно
  */
  private void scanClose(Scanner scan, boolean isNotUsing) throws Exception {
     if (!isNotUsing) {
         throw new Exception("The scanner is still in use");
     } scan.close();
  }

  What в этом комменте не так? А то, что он немножко врёт нам, ведь соединение закрывается, если isNotUsing = false, но ниHow не наоборот, How нам вещает пометка.

• обязательные комментарии — комментарии, которые считают обязательными (Javadoc), но кои по факту иногда бывают излишне нагромождающими, недостоверными и ненужными (нужно задуматься, а нужны ли здесь такие комментарии).

  Пример:

  /**
  *  Creation пользователя по переданным параметрам
  * @param firstName Name созданного пользователя
  * @param middleName среднее Name созданного пользователя
  * @param lastName фамorя созданного пользователя
  * @param age возраст созданного пользователя
  * @param address addressс созданного пользователя
  * @return пользователь который был создан
  */
  User createNewUser(String firstName, String middleName, String lastName, String age, String address);

  Смогли бы вы понять, что делает метод без этих комментариев? Скорее всего да, поэтому комментарии в этом случае стают бессмысленными.

• журнальные комментарии — комментарии, которые иногда добавляют в начало модуля, при каждом его редактировании (что-то вроде журнала вносимых изменений).

  /**
  *  Записи ведутся с 09 января 2020;
  **********************************************************************
  *  09.01.2020  : Обеспечение соединения с БД с помощью Jdbc Connection;
  *  15.01.2020  : Добавление интерфейсов уровня дао для работы с БД;
  *  23.01.2020  : Добавление интеграционных тестов для БД;
  *  28.01.2020  : Имплементация интерфейсов уровня дао;
  *  01.02.2020  : Разработка интерфейсов для сервисов,
  *  согласно требованиям прописанным в user stories;
  *  16.02.2020  : Имплементация интерфейсов сервисов
  *  (реализация бизнес логики связанной с работой БД);
  *  25.02.2020  : Добавление тестов для сервисов;
  *  08.03.2020  : Празднование восьмого марта(Миша опять в хлам);
  *  21.03.2020  : Рефакторинг сервис слоя;
  */

  Когда-то этот проход был оправдан, но с появлением систем управления исходным codeом (например — Git), это стало лишним нагромождением и усложнением codeа.

• комментарии ссылки на авторов — комментарии, преднаmeaningм которых является, указание человека, писавшего code, чтобы можно было связаться и обсудить, How что и зачем:

  * @author  Bender Benderovich

  Опять же, системы контроля версий прекрасно запоминают, кто и когда добавил данный code, и подобный подход излишен.

• تبصرہ شدہ کوڈ وہ کوڈ ہے جس پر کسی نہ کسی وجہ سے تبصرہ کیا گیا ہے۔ بدترین عادات میں سے ایک، کیونکہ آپ نے اس پر تبصرہ کیا اور بھول گئے، اور دوسرے ڈویلپرز میں اسے حذف کرنے کی ہمت نہیں ہے (اگر یہ کوئی قیمتی چیز ہے تو کیا ہوگا)۔

  //    public void someMethod(SomeObject obj) {
  //    .....
  //    }

  نتیجے کے طور پر، یہ ردی کی ٹوکری کی طرح جمع ہوتا ہے. کسی بھی حالت میں ایسا کوڈ نہیں چھوڑنا چاہیے۔ اگر آپ کو واقعی اس کی ضرورت ہے تو، ورژن کنٹرول سسٹم کے بارے میں مت بھولنا۔

• غیر واضح تبصرے وہ تبصرے ہیں جو کسی چیز کو غیر ضروری طور پر پیچیدہ انداز میں بیان کرتے ہیں۔

  /*
      * Начать с массива, размер которого достаточен для хранения
      * всех byteов данных (плюс byteы фильтра) с запасом, плюс 300 byte
      * для данных заголовка
      */
  this.dataBytes = new byte[(this.size * (this.deep + 1) * 2)+300];

  ایک تبصرہ کوڈ کی وضاحت کرنی چاہیے، خود وضاحت کی ضرورت نہیں۔ یہاں کیا ہے؟ "فلٹر بائٹس" کیا ہیں؟ +1 کا اس سے کیا تعلق ہے؟ بالکل 300 کیوں؟

اگر آپ تبصرے لکھنے کا فیصلہ کرتے ہیں، تو ان کو استعمال کرنے کے لیے چند نکات یہ ہیں:

1. ایسے اسٹائلز کا استعمال کریں جو برقرار رکھنے میں آسان ہیں: ایسے اسٹائلز کو برقرار رکھنا جو بہت زیادہ فینسی اور غیر ملکی ہوں پریشان کن اور وقت طلب ہوسکتے ہیں۔
2. لائنوں کے آخر میں ایسے تبصرے استعمال نہ کریں جو ایک لائن کا حوالہ دیتے ہیں: اس سے تبصروں کا ایک بڑا ڈھیر بن جاتا ہے، اور ہر سطر کے لیے اظہار خیال کرنا مشکل ہوتا ہے۔
3. تبصرہ کرتے وقت، "کیسے" کے بجائے سوال "کیوں" کا جواب دینے کی کوشش کریں۔
4. مخففات سے پرہیز کریں۔ جیسا کہ میں نے اوپر کہا، ہمیں تبصرے کے لیے وضاحت کی ضرورت نہیں ہے: تبصرہ ہی وضاحت ہے۔
5. آپ پیمائش کی اکائیوں اور قابل قبول اقدار کی حد کو نشان زد کرنے کے لیے تبصرے استعمال کر سکتے ہیں۔
6. تبصرے اس کوڈ کے قریب رکھیں جو وہ بیان کرتے ہیں۔

نتیجے کے طور پر، میں اب بھی آپ کو یاد دلانا چاہوں گا: بہترین تبصرے تبصرے کی عدم موجودگی ہیں، اور اس کے بجائے، درخواست میں مناسب نام رکھنا۔ ایک اصول کے طور پر، زیادہ تر وقت ہم پہلے سے ہی تیار شدہ کوڈ کے ساتھ کام کر رہے ہوں گے، اسے برقرار رکھنے اور پھیلا رہے ہوں گے۔ جب اس کوڈ کو پڑھنا اور سمجھنا آسان ہو تو یہ بہت زیادہ آسان ہوتا ہے، کیونکہ خراب کوڈ راستے میں آ جاتا ہے، اسپیک کو پہیوں میں ڈال دیتا ہے، اور جلد بازی اس کا وفادار ساتھی ہے۔ اور ہمارے پاس جتنا برا کوڈ ہے، کارکردگی اتنی ہی گرتی ہے، اس لیے ہمیں وقتاً فوقتاً ری ایکٹر کرنے کی ضرورت ہوتی ہے۔ لیکن اگر شروع ہی سے آپ کوڈ لکھنے کی کوشش کرتے ہیں جس کے لیے بعد کے ڈویلپرز آپ کو ڈھونڈ کر آپ کو مارنا نہیں چاہیں گے، تو آپ کو اسے کم کثرت سے ری ایکٹر کرنے کی ضرورت ہوگی۔ لیکن یہ پھر بھی ضروری ہو گا، کیونکہ مصنوعات کے لیے حالات اور تقاضے مسلسل تبدیل ہوتے رہتے ہیں، اضافی کنکشن جوڑ کر اس کی تکمیل ہوتی ہے، اور اس سے کوئی فرار نہیں ہوتا۔ آخر میں، میں آپ کے لیے اس موضوع سے واقفیت کے لیے چند دلچسپ لنکس یہاں چھوڑوں گا ، یہاں اور یہاں میرا اندازہ ہے کہ آج میرے لیے بس اتنا ہی ہے، ہر اس شخص کا شکریہ جنہوں نے پڑھا))