Мета роботи. Вивчити основні способи розробки головного меню додатку. Отримати практичні навички у створенні головного меню програми.
Вказівки щодо використання .NET
У будь-якій мові програмування існують традиційні стилі програмування. Ці стилі є не частиною самої мови, а угодами, скажімо, по іменування змінних або використання певних класів, методів або функцій. Якщо більшість розробників будуть слідувати однаковим угодами, то їм буде простіше зрозуміти код один одного, що, в свою чергу. полегшує підтримку програми. Так, загальним угодою в Visual Basic 6 було те, що рядкові змінні повинні мати імена, що починаються з s або str. наприклад String sResult або String strMessage. Однак угоди залежать від мови і середовища розробки. Програмісти на C ++ для платформи Windows традиційно використовують префікс psz або lpsz для позначення рядків: char * pszResult; char * lpszMessage ;. Але на Unix-машинах такі префікси не застосовуються: char * Result; char * Message; .
Відповідно до угод в С # імена змінних не повинні мати префіксів: string Result; string Message; .
Угода, згідно з яким імена змінних містять префікс. вказує тип даних. відомо як "угорський" стиль іменування об'єктів. При читанні такого коду розробники можуть відразу ж сказати по імені змінної, який тип даних вона представляє.
У той час як для багатьох мов угоди по іменування вироблялися одночасно з розвитком мови, для С # і платформи .NET Microsoft написала докладні рекомендації по використанню, які наведені в документації MSDN для .NET / C #. Отже, з самого початку програми .NET матимуть вищий рівень сумісності за частиною розуміння коду іншими розробниками. Ці рекомендації були розроблені з урахуванням досвіду, отриманого протягом більше двадцяти років об'єктно-орієнтованого програмування, і в результаті є ретельно продуманими і добре сприйняті спільнотою розробників.
Однак необхідно відзначити, що рекомендації не те ж саме, що специфікації мови. Рекомендацій слід дотримуватися в міру можливості. Якщо є вагома причина для їх недотримання, це не буде проблемою. Відхилення від рекомендацій повинно бути викликано реальними причинами, а не простим небажанням.
Одним з важливих моментів є вибір імен для елементів програми: змінних, методів, класів, перерахувань і просторів імен.
Очевидно, що назви мають відображати призначення елемента і не повинні конфліктувати з іншими іменами.
Загальна філософія платформи .NET полягає в тому, що ім'я змінної повинно відображати призначення примірника змінної, а не тип даних.
Наприклад, Height - гарна назва, a IntegerValue - немає. Однак цей принцип є важкодосяжним ідеалом. Зокрема, при роботі з елементами управління в більшості випадків вам буде зручніше використовувати імена змінних, подібні ConfirmationDialog і ChooseEmployeeListBox.
Конкретні рекомендації по іменування включають в себе наступні розділи.
У переважній більшості випадків для імен слід використовувати стиль Pascal. при якому перша буква кожного слова в назві є прописаний
Наприклад: EmployeeSalary, ConfirmationDialog, PlainTextEncoding.
Існують дві ситуації, в яких краще застосовувати таке іменування. Імена всіх параметрів, що передаються в методи, повинні записуватися в стилі camel:
Також можна використовувати camel -соглашеніе для того, щоб відрізнити два елементи, які в іншому випадку мали б однакові імена. Найбільш загальний випадок, коли властивість є оболонкою для поля.
Наведений код є абсолютно коректним з точки зору рекомендацій. Відзначимо, однак, що в цьому випадку слід застосовувати угоду camel для закритих членів і угоду Pascal для відкритих або захищених членів, щоб інші класи, які використовують ваш код, бачили тільки імена в стилі Pascal (за винятком імен параметрів).
У більшості випадків слід застосовувати угоди Pascal. Проте, угода camel рекомендується для закритих змінних, які не видно поза класом, де дві змінні мають однакове призначення. Наприклад, якщо є public властивість, яке інкапсулює private поле з тим же ім'ям, то можна використовувати угоду camel для поля і угоду Pascal для властивості, як в наведеному вище прикладі EmployeeName.
Також необхідно звертати увагу на чутливість до регістру. С # чутливий до регістру, тому синтаксично в С # допустимо, щоб імена розрізнялися лише регістром. Однак потрібно пам'ятати, що ваші збірки можуть бути викликані з додатків VB.NET. a VB.NET не є чутливим до регістру. Тому використовувати імена, що відрізняються тільки регістром, можна лише в тому випадку, якщо вони ніколи не будуть видні поза збірки. В іншому випадку код, написаний в VB.NET. не зможе коректно використовувати вашу збірку.
Необхідно по можливості робити так, щоб стиль всіх імен збігався. Наприклад, якщо один з методів в класі називається ShowConfirmationDialog. то іншого методу не слід давати ім'я ShowDialogWarning або WarningDialogShow. Він повинен називатися ShowWarningDialog.
Імена просторів імен слід вибирати особливо ретельно для того, щоб уникнути використання такого ж імені, яке застосовується десь ще. Необхідно пам'ятати, що .NET розрізняє імена об'єктів в поділюваних збірках тільки по іменах просторів імен. Якщо використовувати для двох пакетів програмного забезпечення одне і те ж ім'я простору імен і встановити обидва пакети на один комп'ютер. виникнуть проблеми. Рекомендується створювати простір імен верхнього рівня з ім'ям вашої компанії, а потім вкладати простору імен, поступово звужуючи їх назви до технології, групи або відділу, де ви працюєте, або до назви пакета, для якого призначені ваші класи. Microsoft рекомендує імена просторів імен, які починаються з <НазваниеКомпании>.<НазваниеТехнологии>. наприклад,