Windows Subsystem for Linux Review

Posted 1 CommentPosted in Programming Practices

Windows Subsystem for Linux Review

Today’s post is for people who use Windows as the main operating system but sometimes need use Linux. 

For a long time I had two operating systems installed. Unfortunately, due to time, I did not have enough disk space, so I decided to look for a better solution. I tested  Windows Subsystem for Linux (WSL) and I think it’s a great solution.

I will try to explain what is WSL, compare to Linux VM or even a Git Bash. 

What is WSL?

The Windows Subsystem for Linux, or WSL, is an optional feature of Windows 10 that lets run GNU/Linux environment and allows Linux programs to run natively on Windows.

The point of WSL is to guarantee a high degree of compatibility with the Linux system ABI kernel to allow programmers working in Windows to use many tools, programs that run natively in Linux without binary modifications.

The official Microsoft website: Windows Subsystem for Linux Documentation

Advantages of WSL

✔️  Allows native launch of LINUX programs and tools.

✔️  WSL requires fewer resources (CPU, memory, and storage) than a full virtual machine.

✔️  You can use Windows and at the same time use the Linux (e.g command line tools).

✔️  Supports multiple GNU/Linux distributions.

✔️  It’s free and very easy to install.

✔️  Has UNIX utilities such as grep, awk, etc. and other advantages of using Linux.

Disadvantages of WSL

❌  You can’t run ALL Linux apps in WSL. WSL is a tool aimed at enabling users who need them to run Bash and core Linux command-line tools on Windows.

❌  WSL is a fresh product and has bugs. If you need all the power and functions of a Linux system, it would be better to run the system on a virtual machine (VM). 

❌  Microsoft did not design or build WSL for production workloads.

❌ WSL allows you to run Linux distributions only in the latest versions of Windows 10 and Windows Server 2016.

❌  WSL does not aim to support GUI desktops or applications e.g. Gnome, KDE, etc.  (But you can install additional program that allows you to open applications… I will explain later how to install it ^^)

WSL is a great tool, but if you really want to take full advantage of Linux, install it as a second system.

Link to GitHub where people report problems to Microsoft / WSL    WSL – issues

WSL vs Git Bash

Both are entirely different things but I want to compare WLS to Git Bash because Git bash gives standard Linux programs. 

Git for Windows (Git Bash) uses the mingwT-w64 and msys2 project (GCC compiler on Windows systems) and is based on the POSIX conformance layer. (POSIX is no longer supported from Windows 8)

In both cases you can use basic Unix commands but in GIT for windows you will not be able to use other programs that only work on Linux or use the GCC compiler.

Install the WSL

A very good guide was prepared by Microsoft about the installation of WSL. How to instal WSL

Personally, I chose the Debian distribution and tested it. After the WSL has been installed, you will be able to open the “Linux” terminal. If you want to run the window applications from the console level, you have to download separate programs (the console can’t display GUI :)).

WSL with Xfce 4

Xfce is a graphical environment designed for UNIX operating systems.

How to install graphical Linux applications and run these under WSL:

  1. You have to have an X server like VcXsrv or Xming, on your Windows machine.
  2. Download and install Xming X Server for Windows. Xming
  3. Enter in the WLS console:
    • sudo apt-get update

    • sudo apt install xfce4

  4. Next, you will need to modify the .bashrc file. (I suggest to use vim or nano)
    • cd ~

    • nano .bashrc

  5. The second command from above will open .bashrc in nano and you can scroll to the end of the file and write:
    • export DISPLAY=:0.0

  6. Save the modified file by pressing CTRL+X and answering Y when asked if you want to save the file. Close and restart the console window.

  7. After installation, start the XLaunch program.

  8. Select display setting
  9. On the next screen, keep the default settings:
  10. On the Extra settings screen, check third option Disable access control:
  11. Press Finish.
  12. Now, in the Bash console window, write:

    • xfce4-session

  13. Finish  

From my experience, Xfce works reasonably well with WSL.

Recommended Literature

If you want to learn more about the Linux command-line applications, I would recommend reading The Linux Command Line by William E.Shotts Jr.


Posted 1 CommentPosted in Programming Practices

Keyboard Shortcuts

Rather, everyone will agree with me that using cursor keys to move to arbitrary positions in a document is silly. But using shortcuts features give you a huge productivity boost. We all like to be efficient. That’s why today’s post will be about keyboard shortcuts. 

.NET Developers are divided into two groups. Some use Visual Studio shortcuts and others ReSharper shortcuts. Below I have listed the most commonly used keyboard shortcuts for Visual Studio users as well as for those who use the ReSharper plugin.

Try to focus on using keys more, for a month or so. You may find it hard going to start with, but your productivity will greatly benefit if you stick at it. But sticking at it is the key.

Visual Studio keyboard shortcuts

I chose the shortcuts, which I use in the VS. I had difficulties to segregate, so the order of the points is accidental.
1.  Autocomplete using IntelliSence  Ctrl + Space

2.  Auto-(Re)Format  Ctrl + K , Ctrl + D

3.  Go to function definition/variable definition (Navigate)  F12

4.  Snippets TAB + TAB

5Start debugging  F5

6.  Stop debugging  Shift + F5

7.  Build project  Ctrl + Shift + B

8.  Comment a block  Ctrl + K ,  Ctrl + C

9.  Uncomment the block  Ctrl + K ,  Ctrl + U

10. Delete Line  Shift + Del

All available shortcuts can be seen in the VS documentation.

Default keyboard shortcuts in Visual Studio

Default keyboard shortcuts for frequently used commands in Visual Studio

Customize keyboard shortcuts in Visual Studio


ReSharper provides two default keyboard shortcuts schemes.

  • Visual Studio
  • ReSharper (IntelliJ)

Whatever scheme you choose, you can always change individual keyboard shortcuts.  If you want to change default keyboard shortcut schemes, use this link

Here’s my list of ReSharper shortcuts that I’ve found to be worth it remembers:

1. Show Action List  Alt + Enter

2. Navigate to Class  Citrl + T

3. Rename  Citrl + RR

4. Refactor This  Citrl + Enter + R

5. Extend Selection  Citrl + Shift  + W

6. Go to File  Citrl + Shift + T

7. Comment a block  Ctrl + K ,  Ctrl + C

8. Make Public/ Private  Alt + Enter

9. Next Method  Alt + Up  /  Previous method  Alt + Down

10. Delete Line  Shift + Del

If you want more shortcuts,  explore the Keyboard Shortcuts page in the official ReSharper documentation.

Default keyboard shortcuts used commands in ReSharper.

Bad Properties

Posted 3 CommentsPosted in Unity

Bad Properties

Most .Net programmers use properties whenever the opportunity arises. This is fully understandable but this good habit is bad for Unity.

In today’s post I will try to explain why you should avoid  properties in the unity engine.

What is a property and Benefits of using them

The usual way of public fields made them unsafe to be accessed (read and write) by any external class that had an access to them. So programmers have come up with a way to have access to a private variable with retain encapsulation. They called it Property.

In short it is special construction very often used in C # (And many other object-oriented languages).
Properties are not just to provide access to the fields; rather, they are supposed to provide controlled access to the fields of our class. As the state of the class depends upon the values of its fields, using properties we can assure that no invalid (or unacceptable) value is assigned to the fields.

The dark side of property

Ok, someone can say “Don’t worry about getter/setters slowing d own your code through indirection. The JIT has a thing called inlineing makes using the getter/setter just as efficient as direct field access.”

Everyone who uses Unity Engine knows that Update is the most commonly used function to implement any kind of game script.  Update is called every frame, if the MonoBehaviour is enabled. So even small allocations or calling another function (properties method)  every frame cause a GC spike in CPU. Unity has a efficient problem… 

Remember, the Update method should be used very carefully. Calmly. Property is not a taboo 😀  Property are  still very useful but they are used rarely.


Posted 6 CommentsPosted in Programming Practices


The previous post concerned the correct writing of the code. After reading this post you could think how to remember the rules and apply them in practice. That’s why today’s post will be about a tool that will help you write the correct code.

ReSharper is not necessary to write code but it is really worth having it. ReSharper increase your C# experience, letting you write error-proof code much faster.

The official ReSharper website:

What is ReSharper?

ReSharper is a it’s a plug-in for Visual Studio that runs on Windows, Mac, and Linux.

The biggest advantages of using ReSharper

  1. Comply with coding standards
  2. Eliminate errors (Quick-fixes) 
  3. Safely change the code

It works much better than in VS ^^.

You can read more information on the official website:

How much does ReSharper cost? Unfortunately, a bit expensive … A commercial license is $129 for the first year, $103 for the second year, and $77 for the third year onwards.


Free individual licenses for students and faculty members

If you are a student like me, you are entitled to a free REshaper license. Most programmers and companies use this plug-in, so I encourage you to try ReSharper.

How to get a free license:

Coding Standards and good writing practices.

Posted 2 CommentsPosted in Programming Practices

Coding Standards and good writing practices.

Why do most programmers pay attention of quality the written code?

You probably know why, but I will repeat it anyway… In the large projects, you have to stick to the rules of code penning because  allowing programers write negligently code cause terrible mess in the project. There will be no time for any corrections, analyzing and expanding projects will consume much more time.

Before I started working in my first job, I thought that, I write a clear and good code but after few days at work I learned, how wrong I was. Thanks to Code Review in my work and Robert C. Martin’s book’s “The Clean Code: A Code of Conduct for Professional Programmers” I could find out what mistakes I made earlier. Now I decided to share my knowledge with you.


Of course, code writing conventions are slightly different in some companies, but the general rules are very similar.

Naming convention

1. Pascal Case & camel Case

Pascal Case and camel Case is the naming convention. Pascal Case is a subset of camel Case where the first letter is capitalized.

camel Case:
  • camelCaseExample

We use for: 

  • local variables
  • function parameters
  • non-public fields
Pascal Case:
  • PascalCaseExample

We use for: 

  • Class
  • Functions
  • Const
  • Property
  • Others not mentioned previously
2. Write in English

If you are not english native like me, remember that the names of variables, methods, classes ect. should be written in English.

3. Interface names always start with “I”
4. Two-letter shortcuts write in uppercase (small for field), more than two-character write in PascalCase
  • IOServer
  • ioServer 
  • CommonWsbFiles  
5. Use and write namespaces.

The namespace system should reflect the directory layout up to the third level of nesting.


6. Tab settings – default for Visual Studio.
7. Avoid too long lines of code.
8. The braces including the code blocks are always set in a new line, i.e. 

  I don’t like java-like code writting.  

9. Each “if” contains braces {} in a new line.
10. Implementation segregation
  1. Events and delegates
  2. Properties
  3. Fields
  4. Constructors and destructors
  5. Methods
  6. Nested Enums, Structs, and Classes.

    Within these groups, order by modifiers:
    1. public
    2. protected
    3. internal
    4. private
11. Avoid using #region. It is used to hide the badly written code.
12. Calling a method with a large number of parameters  is hard to read. If You have to call a method with large number of parameters try keep one parameter per line.
13. Brackets for combining Boolean expressions should look like this:
//Not Ok

if (a<b && c>d)
//do something

if ((a<b) && (c>d))
//do something


14. Avoid creating excessive amounts of DLLs for non-shared code.
15. There is one class or interface per one .cs file. It is allowed to create small auxiliary classes or structures in the same file, but they must be clearly marked (#region, comments)
16.Accessors should not be avoided, when you are defining classes and their elements, i.e:
public class Horse 
int age; // BŁĄD, domyślny akcesor private
private string name; // OK, zdefiniowany akcesor
17. Use the internal modifier where public is not necessary.
18. Use var only when we explicitly know what type will be.q
Ok var text=GESHI_QUOTsome textGESHI_QUOT; Not Ok var someValue=foo.CreateValue();
19. Always check that the delegate is not null (eg throwing an event).
var handler = SomeEvent;
if(handler != null)
20. Avoid using fixed inline (magic numbers) constants. It is better to use const or enum.
21. Avoid explicit projection. Instead, use the “as” conversion operator and check that the returned value is not null.
object dataObject = LoadData(); 
DataSet ds = dataObject as DataSet;
if(ds != null)
22. Automatically generated property is much better than property with backing field when there is no logic for getter and setter.
lass Class
   public int Prop1{get;set;}
   public int Prop2
      get{return prop2;}
      seT{prop2 = value;}
   int prop2;
23. Use the readonly attribute for class fields initialized only in the constructor.
24. Remove unused function and code snippets.


25. There is no obligation to comment on the code inside the function.

..but unintuitively class, fields should have documentation in XML.

26. Use // or /// but avoid / * … * / where possible.
27. Do not embellish your comments. It looks stupid  😛
 // ***************************************
 //  -> Ridiculous comment block <-
 // ***************************************
// ______________________________________


28. Never write an empty catch block. At least Log use is required
29. Avoid nesting a try…catch block inside another catch block.

Recommended literature