قواعد الكود: قوة التسمية الصحيحة، والتعليقات الجيدة والسيئة

كم مرة كان عليك أن تفهم كود شخص آخر؟ عندما تقضي أيامًا بدلاً من بضع ساعات فقط لفهم منطق ما يحدث. الشيء المضحك هو أنه بالنسبة للشخص الذي كتب هذا الرمز، كل شيء واضح وشفاف للغاية. وهذا ليس مفاجئا: بعد كل شيء، الكود المثالي أو المثالي هو مفهوم غامض للغاية، لأن كل مطور لديه رؤيته الخاصة للعالم والكود، على التوالي. واجهت موقفًا أكثر من مرة حيث نظرت أنا وزميلي إلى نفس الكود وكانت لدينا آراء مختلفة حول صحته ونظافته. إنه شعور مألوف، أليس كذلك؟ ومع ذلك، هناك بعض النقاط التي تم اختبارها عبر الزمن والتي يجب الالتزام بها، والتي ستعمل في النهاية لصالحنا، لأنه إذا تركت الكود الخاص بك في الحالة التي ترغب في استلامه بها بنفسك، فسيكون العالم أكثر سعادة قليلاً منظف. في مقالتنا الأخيرة حول قواعد كتابة التعليمات البرمجية (أو بالأحرى دليل صغير)، تطرقنا قليلاً إلى التوصيات الخاصة بكتابة النظام ككل وعناصره مثل الكائنات وواجهاتها وفئاتها وأساليبها ومتغيراتها. هناك ذكرت بإيجاز التسمية الصحيحة لبعض العناصر. اليوم أود أن أتحدث عن هذا بالضبط، لأن الأسماء الصحيحة تجعل قراءة التعليمات البرمجية أسهل بكثير. سنغلق موضوع الكود الصحيح بمساعدة التأملات والأمثلة الصغيرة للتعليقات في الكود - هل هذا جيد أم ليس جيدًا. اذا هيا بنا نبدأ.

التسمية الصحيحة

تعمل الأسماء الصحيحة على تحسين إمكانية قراءة التعليمات البرمجية، وبالتالي توفير الوقت في التعرف عليها، لأنه من الأسهل بكثير استخدام الطريقة عندما يصف الاسم وظيفتها بشكل تقريبي. نظرًا لأن كل شيء في الكود يتكون من أسماء (المتغيرات، الأساليب، الفئات، كائنات الملفات، وما إلى ذلك)، تصبح هذه النقطة مهمة جدًا عند إنشاء كود صحيح ونظيف. بناءً على ما سبق، يجب أن ينقل الاسم معنى سبب وجود المتغير، على سبيل المثال، وماذا يفعل وكيف يتم استخدامه. سأشير مرارًا وتكرارًا إلى أن أفضل تعليق لوصف المتغير هو اسمه الصحيح.

واجهات التسمية

تستخدم الواجهات عادةً الأسماء التي تبدأ بحرف كبير ومكتوبة بأحرف الجمل (CamelCase). لقد كان من الممارسات الجيدة عند كتابة واجهة أن تبدأها بحرف I لتعيينها كواجهة (على سبيل المثال IUserService)، ولكن هذا أمر قبيح ومشتت للانتباه. في مثل هذه الحالات، من الأفضل الكتابة بدونها (UserService)، وإضافة -Impl (UserServiceImpl) إلى تنفيذها. حسنًا، أو كملاذ أخير، أضف البادئة C (CUserService) إلى تنفيذها.

أسماء الفصول

تمامًا مثل الواجهات، تتم كتابة الأسماء بالأحرف الكبيرة وتستخدم نمط الجمل (CamelCase). بغض النظر عن نوع نهاية العالم الذي يحدث، بغض النظر عن مدى سرعة المواعيد النهائية، ولكن لا تتذكر أبدًا، لا ينبغي أن يكون اسم الفصل فعلًا أبدًا! يجب أن تكون أسماء الفئات والكائنات عبارة عن أسماء ومجموعاتها (UserController، وUserDetails، وUserAccount، وما إلى ذلك). لا ينبغي عليك تقديم اسم كل فئة مع اختصار هذا التطبيق، لأن هذا لن يؤدي إلا إلى إضافة تعقيد غير ضروري (على سبيل المثال، لدينا تطبيق ترحيل بيانات المستخدم، وسوف نقوم بإضافة UDM إلى كل فئة - UDMUserDeatils، UDMUserAccount، UDMUserController) ).

أسماء الطريقة

عادةً ما تبدأ أسماء الطرق بحرف صغير، ولكنها تستخدم أيضًا نمط الجمل (CamelCase). تحدثنا أعلاه عن حقيقة أن أسماء الفئات لا ينبغي أن تكون أفعالًا أبدًا. الوضع هنا معاكس تمامًا: يجب أن تكون أسماء الطرق أفعالًا أو مجموعاتها مع الأفعال: findUserById، وfindAllUsers، وcreateUser، وما إلى ذلك. عند إنشاء طريقة (بالإضافة إلى المتغيرات والفئات)، لتجنب الالتباس، استخدم طريقة تسمية واحدة. على سبيل المثال، للعثور على مستخدم، يمكن كتابة الطريقة كـ getUserById أو findUserById. وشيء آخر: لا تستخدم الفكاهة في أسماء الأساليب، لأنهم قد لا يفهمون النكتة، وكذلك ما تفعله هذه الطريقة.

أسماء متغيرة

في معظم الحالات، تبدأ أسماء المتغيرات بحرف صغير وتستخدم أيضًا Camelcase، باستثناء الحالات التي يكون فيها المتغير ثابتًا عامًا. في مثل هذه الحالات، تتم كتابة جميع أحرف الاسم بأحرف كبيرة ويتم فصل الكلمات بشرطة سفلية - "_". عند تسمية المتغيرات، يمكنك استخدام سياق ذي معنى للراحة. بمعنى آخر، عندما يكون هناك متغير كجزء من شيء أكبر - على سبيل المثال، الاسم الأول، الاسم الأخير، الحالة - في مثل هذه الحالات، يمكنك إضافة بادئة تشير إلى الكائن الذي يعد هذا المتغير جزءًا منه. على سبيل المثال: userFirstName، userLastName، userStatus. تحتاج أيضًا إلى تجنب استخدام أسماء متشابهة للمتغيرات عندما يكون لها معاني مختلفة تمامًا. المتضادات الشائعة للمتغيرات:

• البدء/النهاية
• اول الاخر
• مقفل / مقفلة
• الحد الأدنى - الحد الأقصى
• السابق التالي
• قديم / جديد
• مفتوح/مغلق
• مرئي غير مرئي
• المصدر/الهدف
• جهة المصدر
• فوق تحت

أسماء المتغيرات القصيرة

عندما يكون لدينا متغيرات مثل x أو n أو شيء من هذا القبيل، فإننا لا نرى على الفور نية الشخص الذي كتب الكود. ليس من الواضح ما تفعله الطريقة n: فهي تتطلب المزيد من التفكير المدروس (وهذا هو الوقت، الوقت، الوقت). على سبيل المثال، لدينا حقل - معرف المستخدم المسؤول، وبدلاً من بعض الأسماء مثل x أو مجرد معرف، سوف نسمي هذا المتغير ResponsableUserId، مما يزيد على الفور من سهولة القراءة والمعنى. ومع ذلك، فإن الأسماء القصيرة مثل 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 لضبط فرز الدفق ونسيانهما.

الطول الأمثل

دعونا نواصل موضوع طول الاسم. يقع طول الاسم الأمثل في مكان ما بين الحد الأقصى لطول اسم NumberOfUsersInTheCurrentGroup وn. وهذا يعني أن البرامج القصيرة جدًا تعاني من نقص المعنى، والأدوات الطويلة جدًا تمد البرنامج دون إضافة إمكانية القراءة، وهم ببساطة كسالى جدًا بحيث لا يمكنهم كتابتها في كل مرة. مع عدم الأخذ في الاعتبار الحالة المذكورة أعلاه، بالنسبة للمتغيرات ذات الاسم القصير مثل n، تحتاج إلى الحفاظ على الطول حوالي 8 -16 حرفًا. هذه ليست قاعدة صارمة: أكثر من مجرد مبدأ توجيهي.

اختلافات صغيرة

لا يمكنني تجاهل الاختلافات الدقيقة في الأسماء، لأن هذه أيضًا ممارسة سيئة، حيث يمكنك ببساطة أن تصاب بالارتباك أو تقضي الكثير من الوقت الإضافي في ملاحظة الاختلافات الطفيفة في الأسماء. على سبيل المثال، من الصعب اكتشاف الفرق بين InvalidDataAccessApiUsageException وInvalidDataAccessResourceUsageException بنظرة واحدة. أيضًا، يمكن أن تنشأ معلومات خاطئة غالبًا عند استخدام L وO صغيرين، لأنه يمكن الخلط بسهولة بينهما وبين 1 و0: في بعض الخطوط يكون الفرق أكثر وضوحًا، وفي البعض الآخر أقل وضوحًا.

الجزء الدلالي

نحتاج إلى وضع الجزء الدلالي في الأسماء، ولكن لا نبالغ في استخدام المرادفات، نظرًا لأن UserData وUserInfo، على سبيل المثال، لهما نفس المعنى بالفعل، وسيتعين علينا التعمق أكثر في الكود لفهم الكائن المحدد الذي نحتاجه . تجنب الكلمات غير المفيدة، على سبيل المثال، firstNameString: لماذا نحتاج إلى سلسلة الكلمات؟ هل يمكن أن يكون الاسم كائنًا من نوع التاريخ؟ بالطبع لا: لذلك، ببساطة - الاسم الأول. كمثال، أود أن أذكر المتغيرات المنطقية، على سبيل المثال، flagDelete. كلمة العلم لا تحمل أي معنى دلالي. كان من المعقول أن نسميها - isDelete.

التضليل

أود أيضًا أن أقول بضع كلمات حول التسمية غير الصحيحة. لنفترض أن لدينا اسم userActivityList، والكائن المسمى ليس من نوع القائمة، ولكنه حاوية أخرى أو كائن مخصص للتخزين. قد يؤدي هذا إلى إرباك المبرمج العادي: من الأفضل أن نطلق عليه اسمًا مثل userActivityGroup أو userActivities.

يبحث

أحد عيوب الأسماء القصيرة والبسيطة هو أنه من الصعب العثور عليها بكميات كبيرة من التعليمات البرمجية، لأنه ما الذي سيكون من الأسهل العثور عليه: متغير يسمى name أو 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: 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. ضع التعليقات بالقرب من الكود الذي يصفونه.

ونتيجة لذلك، ما زلت أود أن أذكرك: أفضل التعليقات هي عدم وجود تعليق، وبدلا من ذلك التسمية الصحيحة في التطبيق. كقاعدة عامة، سنعمل بالفعل في معظم الأوقات باستخدام تعليمات برمجية جاهزة وصيانتها وتوسيعها. يكون الأمر أكثر ملاءمة عندما يكون هذا الرمز سهل القراءة والفهم، لأن الكود السيئ يعيق الطريق، ويضع إبرة في العجلات، ويكون التسرع هو رفيقه المخلص. وكلما زاد سوء الكود لدينا، انخفض الأداء، لذلك نحتاج إلى إعادة البناء من وقت لآخر. ولكن إذا حاولت منذ البداية كتابة تعليمات برمجية لن يرغب المطورون اللاحقون في العثور عليك وقتلك، فستحتاج إلى إعادة هيكلتها بشكل أقل. ولكن سيظل ذلك ضروريا، لأن شروط ومتطلبات المنتج تتغير باستمرار، وتستكمل بإضافة اتصالات إضافية، ولا يوجد مفر من هذا. أخيرًا، سأترك لك بعض الروابط المثيرة للاهتمام للتعرف على هذا الموضوع هنا وهنا وهنا أعتقد أن هذا كل شيء بالنسبة لي اليوم، شكرًا لكل من قرأ ) )