2024/11/27 下午4:24 Philips XAML Coding Standard

Philips XAML Coding Standard

Version: 1.0
Author: Frankco Lamerikx
Issuer: CCB Coding Standards Philips Healthcare

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=Vl_Uz2DqTtOyMOVLgjDURw&setid=nL2SB11tQk6BeJuXFA… 1/21
2024/11/27 下午4:24 Philips XAML Coding Standard

Introduction
Intro
This document is an attempt to establish a common baseline for XAML and WPF developers.
The guidelines provided here share the following goals:

Increase the readability and uniformity of XAML code.

Decrease the verbosity of XAML code.
Establish common patterns that have proven to be beneficial in the XAML code we have
developed so far.
Establish a common baseline for thinking about code quality in relation to XAML code.

These guidelines are the result of several years of development experience with XAML and WPF.
In those years, a number of pitfalls have been encountered and, sometimes, circumvented. Some
of the guidelines in this document try to make sure that you do not stumble into the same
pitfalls. The work was informed by many contributors, both inside and outside of Philips
Healthcare. You can find their names in the Acknowledgements section.

These guidelines are a living and evolving document. While we continue to use XAML and WPF,
and may even start using WPF 4.5 in the future, we will gain additional knowledge and
experience that will lead to better insights and updates of this document.

The presentation of the guidelines is derived from the Framework Design Guidelines book by
Cwalina and Abrams. Each guideline is presented as a recommendation using Do, Consider,
Avoid, and Do not.

Most guidelines are illustrated with examples or practices, with a good practice indicated by a ✔
and a bad practice by a ✘.

Acknowledgements
The writing of these coding guidelines would not have been possible without the hard work and
valuable insights of the following individuals. The contributors are listed in alphabetical order.
Many of the good suggestions in this document are theirs. As the author, the responsibility for
the bad ones lies solely with me.

Lukasz Berek, Rob van Daal, Jack Geraats, Wilco Furster, Marija Grueva, Eric Heesakkers, Rob van
Manen, Teun van de Merwe, Antoinette van Oeffel, Harold Peeters, Stephan Redering, and Joost
van Rooijen.

Document Layout
The coding standard document consists of a set of rules. Rules are grouped together logically
into so called categories. Each chapter deals with one category. A rule description contains the
following items:

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=Vl_Uz2DqTtOyMOVLgjDURw&setid=nL2SB11tQk6BeJuXFA… 2/21
2024/11/27 下午4:24 Philips XAML Coding Standard

Synopsis. This is a brief description of the rule.

Language. The language item indicates for what language(s) the rule is applicable.
Severity Level. All rules in this coding standard have a level assigned to it, ranging from 1
to 10. Level 1 concerns the most severe issues (program errors), whereas level 10 consists of
the least important rules (style issues). The rules have been distributed evenly over the
available levels to be able to focus on a certain limited set of violations.
Category. This indicates to what category a rule belongs.
Description. The description explains the rule in more detail. Sometimes it also contains a
justification of the rule, possible exceptions and code examples.
Literature References. This section contains references to the origin of the rule. It can also
be used for further reading.

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=Vl_Uz2DqTtOyMOVLgjDURw&setid=nL2SB11tQk6BeJuXFA… 3/21
2024/11/27 下午4:24 Philips XAML Coding Standard

Change History
1.0 2014-10-31
Paul Jansen (TIOBE)
- First official release

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=Vl_Uz2DqTtOyMOVLgjDURw&setid=nL2SB11tQk6BeJuXFA… 4/21
2024/11/27 下午4:24 Philips XAML Coding Standard

Miscellaneous Best Practices

MIS$001
Do be aware that windows, dialogs, message boxes, and popups are the root of
Synopsis
their own visual tree
Level 1
Category Miscellaneous Best Practices
Status Checked
Do be aware that windows, dialogs, message boxes, and popups are the root of their own visual
tree, and as such they do not "inherit" properties that are set on the UI element that owns them.
In particular, this means that if you want to have uniform usage of fonts throughout your
application, you will have to set the font family, font size, etc. for each window, dialog, message
box, or popup. The same goes for other window related properties such as the cursor. Failure to
do so will mean that your custom window uses the values that are provided by the Microsoft
default Microsoft styles.

The following example illustrates how to define a new custom window in XAML and set the font
to 15pt Philips Healthcare Font, which is defined as a resource elsewhere.

✔ <Window x:Class="MyCustomWindow"
FontFamily="{Window PhilipsHealthcareFont}"
FontSize="14"/>

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=Vl_Uz2DqTtOyMOVLgjDURw&setid=nL2SB11tQk6BeJuXFA… 5/21
2024/11/27 下午4:24 Philips XAML Coding Standard

Naming Conventions
NAM$001
Synopsis Do use US English
Level 1
Category Naming Conventions
Status Checked
US English, also called American English, is the language that we use professionally within Philips
Healthcare. It should also be the language that you use for your XAML coding. To guarantee
consistency, it is important to stick to US English, and not mix US English and UK English (or any
other kind of English, for that matter).

✘ <Color x:Key="AnnotationBlueColour"/>

✔ <Color x:Key="AnnotationBlueColor"/>

NAM$002
Synopsis Consider giving each logical XAML element a unique name
Level 1
Category Naming Conventions
Status Checked
It is good practice to consider giving each logical XAML element a unique name. This will make
it possible to refer to the elements in code. It will also facilitate debugging, since the unique
names will be shown in popular debugging tools such as Snoop.

NAM$003
Synopsis Do use x:Name instead of Name to give XAML elements a unique name
Level 1
Category Naming Conventions
Status Checked
At first sight, the x:Name and Name properties appear to be the same, but in fact they are not.
The x:Name directive is used to uniquely identify XAML elements in a XAML name scope. The
Name, on the other hand, is a property of WPF's FrameworkElement class. However, since not all
XAML elements represent FrameworkElement instances, it will not always work to assign the
Name property to a XAML element. This means that x:Name can be used on a wider range of
objects, and is the preferred way of giving XAML elements a unique name.

✘ <Button Name="cancelButton"/>

✔ <Button x:Name="cancelButton"/>

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=Vl_Uz2DqTtOyMOVLgjDURw&setid=nL2SB11tQk6BeJuXFA… 6/21
2024/11/27 下午4:24 Philips XAML Coding Standard

NAM$004
Synopsis Do use x:Key to give resources a unique name
Level 1
Category Naming Conventions
Status Checked
The x:Key directive is used to uniquely identify elements that are created and referenced in a
XAML resource dictionary. It is the most common and preferred way to identify a resource in a
resource dictionary

✔ <Color x:Key="AnnotationBlueColor"/>

✔ <Style x:Key="ButtonStyle" TargetType="{x:Type Button}">

NAM$005
Synopsis Avoid giving a XAML element both an x:Key and an x:Name
Level 1
Category Naming Conventions
Status Checked
The x:Key directive should be reserved for resources. The x:Name directive should be used for all
other XAML elements. If a resource is given both an x:Key and an x:Name, the x:Name is
considered negligible and will have no effect.

NAM$006
Synopsis Do use camel casing for the x:Name
Level 1
Category Naming Conventions
Status Checked
The x:Name is equivalent to a variable or a private field that holds an object reference or an
instance as returned by a constructor. Therefore, the same naming conventions should apply
that apply to variables or private fields in C#.

✘ <Button x:Name="CancelButton"/>

✔ <Button x:Name="cancelButton"/>

NAM$007
Synopsis Do use Pascal casing for the x:Key
Level 1
Category Naming Conventions
Status Checked

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=Vl_Uz2DqTtOyMOVLgjDURw&setid=nL2SB11tQk6BeJuXFA… 7/21
2024/11/27 下午4:24 Philips XAML Coding Standard

The x:Key can be thought of as a constant defining a resource. Therefore, the same naming
conventions should apply that apply to constants or constant fields in C#.

✘ <Color x:Key="annotationBlueColor"/>

✔ <Color x:Key="AnnotationBlueColor"/>

NAM$008
Synopsis Do postfix the x:Name with the type of the XAML element
Level 1
Category Naming Conventions
Status Checked
Again, the same naming conventions should apply that apply to variables in C#. We strongly
recommend against prefixing the x:Name with the type, or even an abbreviation of the type, as
is often seen in third party code on the Internet.

✘ <Button x:Name="btnCancel"/>

✘ <Button x:Name="buttonCancel"/>

✔ <Button x:Name="cancelButton"/>

NAM$009
Synopsis Do postfix the x:Key with the type of the XAML element
Level 1
Category Naming Conventions
Status Checked
This rule is similar to the one for x:Name.

✘ <Color x:Key="AnnotationBlueColor"/>

✘ <Color x:Key="colorAnnotationBlue"/>

✔ <Color x:Key="AnnotationBlueColor"/>

NAM$010
Synopsis Consider providing meaningful names for your XAML elements
Level 1
Category Naming Conventions
Status Unchecked
The benefits of providing meaningful names should be obvious.

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=Vl_Uz2DqTtOyMOVLgjDURw&setid=nL2SB11tQk6BeJuXFA… 8/21
2024/11/27 下午4:24 Philips XAML Coding Standard

✘ <Border x:Name="bd"/>

✘ <Border x:Name="border1"/>

✔ <Border x:Name="outlineBorder"/>

NAM$011
Synopsis Do prefix the x:Name of template parts with PART_
Level 1
Category Naming Conventions
Status Unchecked
Template parts are all those parts of a control template that a control (i.e., the code behind)
expects, and without which the control cannot work or can only work with limited functionality.
By convention, all the template parts should have the PART_ prefix. Nothing else should have
this prefix.

✔ <Border x:Name="PART_CloseButton"/>

✔ <ItemsControl x:Name="PART_ItemsControl"/>

NAM$012
Synopsis Consider using brief or abbreviated namespace aliases
Level 1
Category Naming Conventions
Status Checked
Namespace aliases, particularly those that refer to private namespaces, will appear in your XAML
as prefixes to XAML elements from those namespaces. To keep the XAML from getting
extravagantly verbose, it is recommended to use short or even abbreviated namespace aliases.

✘ xmlns:presentation="clr-namespace:Philips.Platform.Presentation"

✔ xmlns:pt="clr-namespace:Philips.Platform.Presentation"

NAM$014
Synopsis Do use lowercase letters for namespace aliases
Level 1
Category Naming Conventions
Status Checked
It is common practice to use all lowercase letters for namespace aliases.

✘ xmlns:Sys="clr-namespace:System;assembly=mscorlib"

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=Vl_Uz2DqTtOyMOVLgjDURw&setid=nL2SB11tQk6BeJuXFA… 9/21
2024/11/27 下午4:24 Philips XAML Coding Standard

✔ xmlns:Sys="clr-namespace:System;assembly=mscorlib"

NAM$015
Synopsis Consider using the same namespace aliases throughout your project
Level 1
Category Naming Conventions
Status Checked
Using the same namespaces aliases in all XAML files increases uniformity, readability, and
discoverability of your XAML code. You should also consider always using the following standard
namespace aliases for well-known namespaces:

✔ xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

✔ xmlns:d="http://schemas.microsoft.com/expression/blend/2008"

✔ xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"

✔ xmlns:po="http://schemas.microsoft.com/winfx/2006/xaml/presentation/options"

✔ xmlns:sys="clr-namespace:System;assembly=mscorlib"

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=Vl_Uz2DqTtOyMOVLgjDURw&setid=nL2SB11tQk6BeJuXF… 10/21
2024/11/27 下午4:24 Philips XAML Coding Standard

Organization and Layout

ORG$001
Synopsis Do make the x:Name directive the first property after a XAML type instance
Level 1
Category Organization and Layout
Status Checked
Having the x:Name directive always in the same place increases uniformity, readability, and
discoverability of your XAML code.

✘ <Button x:Name="cancelButton" Content="Cancel" Height="38"/>

✔ <Button Content="Cancel" x:Name="cancelButton" Height="38"/>

ORG$002
Consider putting the XAML element type and the x:Name together on the first
Synopsis
line
Level 1
Category Organization and Layout
Status Checked
Putting the XAML type and the x:Name on the same line lets the reader of your code glance
both the type and the unique name of a XAML element at once. It is almost like declaring a
variable in C# code. You should also consider putting nothing else on the same line as the XAML
type and the x:Name.

✔ <Button x:Name="cancelButton"
Content="Cancel"
Height="38"/>

ORG$003
Synopsis Consider putting the Style property on the second line
Level 1
Category Organization and Layout
Status Checked
If it is necessary to explicitly define a style for a XAML element, you should consider putting this
on the second line. The style defines what your XAML element will look like, and all the other
properties are either extensions to or deviations from this style.

✘ <Button x:Name="closeButton"
Width="38" Height="38"/>

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=Vl_Uz2DqTtOyMOVLgjDURw&setid=nL2SB11tQk6BeJuXF… 11/21
2024/11/27 下午4:24 Philips XAML Coding Standard

Style="{DynamicResource CloseButtonStyle}"/>

✔ <Button x:Name="closeButton"
Style="{DynamicResource CloseButtonStyle}"
Width="38" Height="38"/>

ORG$004
Synopsis Consider putting related properties on the same line
Level 1
Category Organization and Layout
Status Checked
Some XAML properties naturally belong together. Examples of this are Width and Height, or
HorizontalAlignment and VerticalAlignment. You should consider grouping these properties in
such a way that they appear on the same line. Distributing related properties over multiple lines
will make your XAML files unnecessarily long. As a counterpart, you should also consider putting
nothing else on a line that has naturally related properties.

✘ <Button x:Name="cancelButton"
Content="Cancel"
Width="120" Height="38" HorizontalAlignment="Center"
VerticalAlignment="Center"/>

✘ <Button x:Name="cancelButton"
Content="Cancel"
Width="120"
Height="38"
HorizontalAlignment="Center"
VerticalAlignment="Center"/>

✔ <Button x:Name="cancelButton"
Content="Cancel"
Width="120" Height="38"
HorizontalAlignment="Center" VerticalAlignment="Center"/>

ORG$005
Synopsis Organize properties in the right order
Level 1
Category Organization and Layout
Status Checked
Consider organizing the properties as follows:

1. XAML element type and x:Name;

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=Vl_Uz2DqTtOyMOVLgjDURw&setid=nL2SB11tQk6BeJuXF… 12/21
2024/11/27 下午4:24 Philips XAML Coding Standard

2. The Style property;

3. Attached properties, such as Grid.Row, Grid.Column, or DockPanel.Dock;
4. Properties related to the content of the UI element, such as Content, ToolTip, or Text;
5. Properties related to the layout of the UI element, such as Width, Height, Margin,
HorizontalAlignment, VerticalAlignment, Stretch, etc.;
6. Properties related to the visibility of the UI element, such as Visibility and Opacity.

The following example illustrates these organization principles. In this example, we define a
custom button that is put in the second row and third column of a grid (note that grids use zero-
based indexing of their rows and columns). Furthermore, the custom button has custom content
and a custom tooltip, and has several layout properties set. We apply the previous
recommendation of putting related properties on the same line. The custom button is intended
not to be visible by default - a trigger (not shown here) will take care of making the button
visible under the right conditions.

✔ <Button x:Name="myCustomButton"
Style="{DynamicResource MyCustomButtonStyle}"
Grid.Row="1" Grid.Column="2"
Content="My custom button content"
ToolTip="My custom button tooltip"
Width="120" Height="38"
HorizontalAlignment="Center" VerticalAlignment="Center"
Margin="6,0"
Visibility="Hidden"/>

ORG$006
Synopsis Avoid giving properties a default value
Level 1
Category Organization and Layout
Status Checked
XAML is quite verbose. You should avoid adding to the verbosity by specifying property values
that the XAML parser can infer by default. A typical example of this is assigning the value 0 to
the Margin and Padding properties. There are other examples, though, and you should be aware
of them. You should also be aware that automated tools that generate XAML, such as Microsoft
Expression Blend, don't always remove these redundant property values, and are therefore
suboptimal in this respect.

✘ <Button x:Name="closeButton"
Style="{DynamicResource CloseButtonStyle}"
Margin="4,4,4,4"
Padding="2,0,2,0"/>

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=Vl_Uz2DqTtOyMOVLgjDURw&setid=nL2SB11tQk6BeJuXF… 13/21
2024/11/27 下午4:24 Philips XAML Coding Standard

✔ <Button x:Name="closeButton"
Style="{DynamicResource CloseButtonStyle}"
Margin="4"
Padding="2,0"/>

ORG$007
Synopsis Consider using the concise format for attribute value assignment
Level 1
Category Organization and Layout
Status Checked
Again, you should try not to add to the natural verbosity of XAML. Attributes such as Margin and
Padding accept abbreviated values that apply in the order provided, symmetrically and logically.
For instance, Margin="20" will be interpreted to mean a Thickness with all properties set to 20.
Margin="20,50" will be interpreted to mean a Thickness with Left and Right set to 20, and Top
and Bottom set to 50.

✘ <Button x:Name="closeButton"
Style="{DynamicResource CloseButtonStyle}"
Margin="4,4,4,4"
Padding="2,0,2,0"/>

✔ <Button x:Name="closeButton"
Style="{DynamicResource CloseButtonStyle}"
Margin="4"
Padding="2,0"/>

ORG$008
Synopsis Consider using the concise format for assigning the path of a binding expression
Level 1
Category Organization and Layout
Status Checked

✘ Cursor="{Binding Path=Cursor, Source={StaticResource DefaultCursor}}"

✔ Cursor="{Binding Cursor, Source={StaticResource DefaultCursor}}"

ORG$009
Synopsis Do use spaces instead of tabs in your XAML files
Level 1
Category Organization and Layout
Status Checked

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=Vl_Uz2DqTtOyMOVLgjDURw&setid=nL2SB11tQk6BeJuXF… 14/21
2024/11/27 下午4:24 Philips XAML Coding Standard

Do use spaces instead of tabs in your XAML files.

ORG$010
Synopsis Do use an indentation of four spaces in your XAML files
Level 1
Category Organization and Layout
Status Checked
Do use an indentation of four spaces in your XAML files.

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=Vl_Uz2DqTtOyMOVLgjDURw&setid=nL2SB11tQk6BeJuXF… 15/21
2024/11/27 下午4:24 Philips XAML Coding Standard

Resources
RES$001
Synopsis Do use StaticResource if you can, DynamicResource if you must
Level 1
Category Resources
Status Unchecked
In XAML, resources can be referred to either statically or dynamically. There are benefits to using
static resources, such as better performance and better compile-time checks. It is not always
possible to use a static resource, though. In general, the compiler must be able to resolve a
reference to a static resource at compile-time. If this is not possible, you should use a dynamic
resource instead. If you need skinning or theming, you will also need dynamic resources,
because a resource may have a different definition for different themes.

RES$002
Synopsis Do use StaticResource to define the based-on type for implicit styles
Level 1
Category Resources
Status Checked
If you define an implicit style (see below for why you should want to define implicit styles), you
have no choice but to use a static resource, even if the resource cannot be resolved at compile-
time. On purpose, it is not allowed to use a dynamic resource in a based-on style.

✔ <!-- Define an implicit style.

Note that an implicit style should not have an x:Key. -->
<Style
BasedOn="{StaticResource MyCustomButtonStyle}"
TargetType="{x:Type Button}">
<Setter Property="Width" Value="120"/>
<Setter Property="Height" Value="38"/>
</Style>

RES$003
Synopsis Consider freezing objects that are freezable
Level 1
Category Resources
Status Checked
WPF provides freezable types. These are types that derive from System.Windows.Freezable.
Freezable types provide detailed change information and can be made immutable (frozen). This

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=Vl_Uz2DqTtOyMOVLgjDURw&setid=nL2SB11tQk6BeJuXF… 16/21
2024/11/27 下午4:24 Philips XAML Coding Standard

is particularly useful if you define resources that are expensive to modify or copy, and that you
know will never change during their lifetime. By freezing these resources, you tell the runtime
not to observe any possible modifications to these objects. This improves application
performance. Typical examples of freezable objects include brushes, pens, transformations,
geometries, and animations. In order to freeze a resource in XAML, you should include the
following namespace. Not all XAML readers recognize the Freeze attribute that is defined in this
namespace, so it is recommended to mark the namespace as ignorable.

✔ xmlns:po="http://schemas.microsoft.com/winfx/2006/xaml/presentation/options"
mc:Ignorable="po"
After doing so, you can freeze the object as follows:

✔ <SolidColorBrush x:Key="TextBrush" po:Freeze="True" Color="Black"/>

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=Vl_Uz2DqTtOyMOVLgjDURw&setid=nL2SB11tQk6BeJuXF… 17/21
2024/11/27 下午4:24 Philips XAML Coding Standard

Styles
STY$001
Do specify the target type of your style using the TargetType="{x:Type
Synopsis
TypeName}" syntax
Level 1
Category Styles
Status Checked
If you need to specify the target type of your style explicitly, you should favor the syntax that
uses the x:Type markup extension. The reason for this is primarily that it guarantees consistency
in your XAML code, but also that the use of the Typename-as-String alternative may lead to
problems.

✘ <Style x:Key="MyCustomButtonStyle" TargetType="Button"/>

✔ <Style x:Key="MyCustomButtonStyle" TargetType="{x:Type Button}"/>

This recommendation also holds for other attributes that expect a Type value, such as
ControlTemplate.TargetType or RelativeSource.AncestorType.

STY$002
Synopsis Consider introducing implicit styles to avoid duplication of XAML code
Level 1
Category Styles
Status Checked
Sometimes, your XAML needs to define a number of elements of the same type that should all
have certain properties set in the same way. In order to avoid duplication of XAML code, you
should consider defining a local implicit style to take care of all the commonalities. Implicit styles
are one of the most powerful tools that the XAML developer has to increase the uniformity of
the UI elements, and to enhance the readability and the maintainability of the XAML code.

The following example illustrates the use of an implicit style based on an existing custom button
style that sets the width and height for a collection of buttons.

✘ <!-- If you do not define an implicit style, each of the properties must be set
explicitly for each button, even if, by design, a property should have the
same value for multiple buttons. -->
<Button x:Name="okButton"
Content="OK"
Width="120" Height="38"/>
<Button x:Name="cancelButton"

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=Vl_Uz2DqTtOyMOVLgjDURw&setid=nL2SB11tQk6BeJuXF… 18/21
2024/11/27 下午4:24 Philips XAML Coding Standard

Content="Cancel"
Width="120" Height="38"/>

✔ <!-- Define an implicit style.

Note that an implicit style should not have an x:Key. -->
<Style
BasedOn="{StaticResource MyCustomButtonStyle}"
TargetType="{x:Type Button}">
<Setter Property="Width" Value="120"/>
<Setter Property="Height" Value="38"/>
</Style>
...
<!-- The implicit style will be applied to these buttons without explicitly
setting it. This means that the OK and the Cancel button will both have
the width and the height that is specified by the implicit style. -->
<Button x:Name="okButton"
Content="OK"/>
<Button x:Name="cancelButton"
Content="Cancel"/>

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=Vl_Uz2DqTtOyMOVLgjDURw&setid=nL2SB11tQk6BeJuXF… 19/21
2024/11/27 下午4:24 Philips XAML Coding Standard

Value Converters
VAL$002
Synopsis Consider enhancing your custom value converters with markup extensions
Level 1
Category Value Converters
Status Unchecked
To use a custom value converter in XAML, you usually have to define a resource for it, and use
the resource key to reference your converter, as illustrated by the following XAML code snippets
(here, "mcn" denotes "my custom namespace").

First, define a resource for your custom converter:

1. <:mcn:MyCustomConverter x:Key="MyCustomConverter"/>
Next, use your custom convertor:

2. SomeProperty="{Binding
SomeBindableProperty,
Converter={StaticResource MyCustomConverter}
}"

As you can see, this leads to rather verbose XAML. If, on the other hand, you implement a
markup extension that enhances your custom converter by providing a static instance of your
converter, then the XAML becomes less verbose. First of all, the markup extension eliminates the
need to define a resource for your custom converter: line (1) from the example above is no
longer needed. Second, the syntax for the binding that uses the converter becomes simpler:

✔ SomeProperty="{
Binding SomeBindableProperty
Converter={mcn:MyCustomConverter}
}"
There are various ways to implement a markup extension for your custom converters. You can
either let your converter class derive from MarkupExtension, while still implementing one of the
value conversion interfaces, IValueConverter or IMultiValueConverter; or you can restrict the role
of your converter class to implementing one of the value conversion interfaces, and create an
additional class to act as the markup extension for your converter.

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=Vl_Uz2DqTtOyMOVLgjDURw&setid=nL2SB11tQk6BeJuXF… 20/21
2024/11/27 下午4:24 Philips XAML Coding Standard

Literature

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=Vl_Uz2DqTtOyMOVLgjDURw&setid=nL2SB11tQk6BeJuXF… 21/21