Principle of Least Surprise 😳

Principle Statement :

In interface design, always do the least surprising thing. 😨

Description :

Never surprise the user. ❌

An interface should behave exactly as the user thinks it behaves. ✅

What surprises the user depends on the kind of interface and the type of user. 🖥

The central idea of PLS is to think about how the user would want to use the interface. 🤳🏻

Principle of least astonishment is when you, as an API designer, prevent your users from saying WAT. 😱

🔸🔹🔸🔹

Examples :

1️⃣ Consider an elevator with a button next to it that says "call". ☎️

When you press the button, the payphone phone rings (rather than calling the elevator to that floor). ❌

The correct design would be to put the call button next to the phone rather than the elevator. ⛓


2️⃣ Think of a web page that has popup window that shows a windows style error with an 'ok' button on it. 🆗

People click the 'ok' button thinking it is for the operating system and instead go to another web page. 🌐

This astonishes the user. 😦


3️⃣ The name of a function should reflect what it does. Otherwise, a user of the function will be unpleasantly surprised❗️

Bad :

int multiply(int a, int b)
{
   return a + b;
}

Better :

int multiply(int a, int b)
{
   return a * b;
}

🔹🔸🔹🔸

When it comes to an API ... 👾

• Think about a toString() method that instead of printing out the fields returns back "to be implemented". 🤥

• An equals() method that works on hidden information. 👁

• Sometimes people try to implement a sorted list class by changing the add method to call sort() on the array afterwards. 🗂

This astonishing because the add method is supposed to append to the list. 🗳

This is especially astonishing when one gets back a List object with no knowledge that somewhere deep inside, someone violated the interface contract. 🤔

Having a method that does one distinct thing contributes to reduction of astonishment. ✅

https://t.me/pgimg/115

〰〰〰〰〰〰
#Principle #PLS
@ProgrammingTip