WPF Code Rules

이 레포지토리는 Hask-Team이 관리하고 있습니다. (이는 연습을 위한 Demo 자료입니다.)

더 알아보기 »

소개

• 핵심 DLL
• 코드 스타일
• Try Catch
• Code Quality Check
• Resources

핵심 DLL

• System.Xaml
• WindowsBase
• PresentationCore
• PresentationFramework

코드 스타일

• Property
• Region

Property

• Property

  public string Email { get; set; }

• Get Set Property

  private string _email;
  public string Email 
  { 
      get { return _email; } 
      set { _email = value; } 
  }

  Be sure to name the private access restrictor for the variable.

• Observable Property

  private string _email;
  public string Email 
  { 
      get { return _email; } 
      set { _email = value; OnPropertyChanged(); } 
  }

  Do not recommended to use .base for prefixes.
  ❌ base.OnPropertyChanged();    ✔️ OnPropertyChanged();

• Property with method in setter

  private string _email;
  public string Email 
  { 
      get { return _email; } 
      set { _email = value; OnPropertyChanged(); EmailChanged(value); } 
  }

Region

#region Email

private string _email;
public string Email
{
    get { return _email; }
    set { _email = value; OnPropertyChanged(); EmailChanged(value); }
}
#endregion

---

Try Catch

❗ Try Catch is generally not recommended.

Errors in the Try Catch area are not reflected in the program's operating cycle, which can cause application flow problems. To avoid this, it is not recommended to use Try Catch from the development stage.

Especially, WPF applications that maintain organic flow to .Xaml and .cs and Resource areas have an advantage in not using Try Catch from the development stage. It is recommended that you use a combination of While statements to implement code that induces repetition of the Try Catch area and allows the user to control it.

👉 Situation that Try Catch should be used

When you need to check the success of the action through Try Catch.

• Local File Access
• Crawling
• API
• External Connection

---

Code Quality Check

◾ Remove unused xmlns:local

<UserControl x:Class="TestProject.Views.TestUserControl"
             xmlns:local="clr-namespace:TestProject.Views;assembly=TestProject">
         ...
</UserControl>

◾ Decalre connected resource

Check the location of the style resource in use and make sure it is properly declared in App.xaml.

◾ Classify each control style

Create styles of all controls to match each name rule.

◾ Remove unused x:Name

Discard declared reckless name properties for access, such as .cs in View or ViewModel, and find a way to bypass them.

◾ Remove unused using

👉 Why we should remove unused using? (TBD...)

• Readability
• Unnecessary code
• Namespace redundancy, conflict issues
• Understanding of object-oriented structures of C#

---

Resources

Resource Rule is so important in WPF programs that you have to put more effort into than the program's UI design. Therefore, we would like to provide a guide to the main resources used by WPF in as much detail as possible.

❗ Strong Name

Managing the resource system in a project is very complex and difficult. So, it is very important to abide by strict and strong naming rules from start to finish, and it requires continued patience.

❗ Do not write without rules.

Temporarily creating resource without rules is a very bad way to develop them. This is because unmanaged resources accumulate, greatly hindering the readability and functional scalability of all program logic. Also, disorderly resources will continue to torment developers until the end of the program's life cycle. Therefore, it is important to make and maintain rules even if it is annoying at the time.

Style Classification Tree Structure

• Visual

  • ContentControl
    • Button
    • ToggleButton
    • RadioButton
    • CheckBox
  • Control
    • TextBox
  • FrameworkElement
    • TextBlock
  • ItemsControl
    • ListBox (with ListBoxItem)
    • TreeView (with TreeViewItem)

• Design

  • SolidBrush
  • Path
  • Geometry
  • Drawing

  👉 The reason for the detailed classification of styles.

    If WPF properties are applied directly from the screen under development, source code readability, simplicity and quality can no longer be expected. Therefore, style rules and names should be intuitive and designed to infer functions and intentions.

ContentControl

Control	Naming	Namespace	Inheritance Flow
Button	BTN	System.Windows.Controls	Button > ButtonBase > ContentControl > Control > FrameworkElement > UIElement > Visual > DependencyObject
ToggleButton	TGL	System.Windows.Controls.Primitives	ToggleButton > ButtonBase > ContentControl > Control > FrameworkElement > UIElement > Visual > DependencyObject
RadioButton	RDO	System.Windows.Controls	RadioButton > ToggleButton > ButtonBase > ContentControl > Control > FrameworkElement > UIElement > Visual > DependencyObject
CheckBox	CHB	System.Windows.Controls	CheckBox > ToggleButton > ButtonBase > ContentControl > Control > FrameworkElement > UIElement > Visual > DependencyObject

Control

Control	Naming	Namespace	Inheritance Flow
TextBox	TXT	System.Windows.Controls	TextBox > TextBoxBase > Control > FrameworkElement > UIElement > Visual > DependencyObject

FrameworkElement

Control	Naming	Namespace, Inheritance Flow
TextBlock	TXB	◾ System.Windows.Controls ◽ TextBlock > FrameworkElement > UIElement > Visual > DependencyObject

ItemsControl

Control	Naming	Namespace	Inheritance Flow
ListBox	LBX	System.Windows.Controls	ListBox > Selector > ItemsControl > Control > FrameworkElement > UIElement > Visual > DependencyObject
TreeView	TRV	System.Windows.Controls	TreeView > ItemsControl > Control > FrameworkElement > UIElement > Visual > DependencyObject

References

Markdown

• Temp Link
• the-easiest-markdown