DEV Community: Chakrit Wichian

If/Else Pyramids

Chakrit Wichian — Wed, 17 Mar 2021 17:48:32 +0000

When writing complex method or important "core logic" code paths. We often need to add many branching and condition switches. If we are not careful, we can end up with a "pyramid" built on indentation upon indentation due to the need to add conditional branches over and over during the liftime of the code as new business logic are discovered and handled.

Often, however, the method usually do have a central "happy path" that does the most meaningful and important work. We can focus on highlight this "happy path" to keep the method obvious as to its purpose and remains highly readable.

Example

class Payment
  attr_reader :method
  attr_reader :card_number
  attr_reader :wallet_address
  attr_reader :paid

  def process
    if !paid
      if method == :credit_card
        if !Luhn.check(self.card_number)
          raise 'invalid CC number'
        else
          CreditCard.process(self)
        end
      elsif method == :bitcoin
        if !BTC.check_address(self.wallet_address)
          raise 'invalid BTC wallet address'
        else
          BTC.process(self)
        end
      end
    end
  end
end

There are several strategy we can "streamline" the code path, making the gist of the method, which is to process payments, obvious. The first of which is to inverts the if/else statement and deal with failure condition early.

Notice the outermost if !paid block. This block covers the entirety of the method. This means that the simple "is this payment paid?" check adds to the rest of the method 1 extra level of indentation that does not serve a lot of purpose and keeps the "happy path" 1 level away from the method main scanline.

The first and simplest fix to improve the readability, is simply:

Instead of

def process
  if !paid
    if method == :credit_card
      if !Luhn.check(self.card_number)
        raise 'invalid CC number'
      else
        CreditCard.process(self)
      end
    elsif method == :bitcoin
      if !BTC.check_address(self.wallet_address)
        raise 'invalid BTC wallet address'
      else
        BTC.process(self)
      end
    end
  end
end

Do this

def process
  return if paid

  if method == :credit_card
    if !Luhn.check(self.card_number)
      raise 'invalid CC number'
    else
      CreditCard.process(self)
    end
  elsif method == :bitcoin
    if !BTC.check_address(self.wallet_address)
      raise 'invalid BTC wallet address'
    else
      BTC.process(self)
    end
  end
end

Why?

When reading normal text in a book, we expect lines to line up. Deviating from the norm sends a signal to the reader that something is different, or off, about the code.

However, by wrapping the entire method in an if/else block we make the entire content of the method reads a little bit harder just for the sake of this one particular condition check which is not the primary purpose of the method at all.

Inverting the condition so that we can check the paid condition and exit early leaves the rest of the method at 1-indentation, like any other regular method.

This improves readability, for two reasons:

It allows reader to "discard" the paid condition from their mind early when reading the method. Allowing more cognitive space when debugging.
It highlights the gist of the method, which should be about processing the payment, not the noises from conditional checks.

Why Not?

Most of time, we can take this simple technique and re-apply it all the way until we're left with almost no indentation at all:

def process
  return if paid
  raise 'bad CC number'  if method == :credit_card && !Luhn.check(self.card_number)
  raise 'bad BTC wallet' if method == :bitcoin     && !BTC.check_address(self.wallet_address)

  if method == :credit_card
    CreditCard.process(self)
  elsif method == :bitcoin
    BTC.process(self)
  end
end

Now it is very obvious that the method is about delegating the procesing of payments to the right processor class (CreditCard for credit cards and BTC for bitcoins.)

However, experienced coder will notice that we're also muddying the validation of each processor as a cost of doing this as well. Processing credit cards now requires scanning through the .process method for the second line (doing the luhn check) and then skip to the method check to see that the actual processing is done in another class.

Additionally we have also modified the code flow. The validation checks are now performed separately from the processing block. If we are not careful during real production code edits, we may introduce subtle bugs due to the changed code paths and other developers who need to work on this piece of code may not realize that there is a code pattern to be followed here (validate before processing).

Split Condition

Alternatively, another strategy we can use to deal with conditional pyramids is to separate the actual processing out of the conditional branching.

Instead of

def process
  return if paid

  if method == :credit_card
    if !Luhn.check(self.card_number)
      raise 'invalid CC number'
    else
      CreditCard.process(self)
    end
  elsif method == :bitcoin
    if !BTC.check_address(self.wallet_address)
      raise 'invalid BTC wallet address'
    else
      BTC.process(self)
    end
  end
end

Do this

def process
  return if paid

  if method == :credit_card
    process_credit_card
  elsif method == :bitcoin
    process_bitcoin
  end
end

def process_credit_card
  raise 'invalid CC number' if !Luhn.check(self.card_number)
  CreditCard.process(self)
end

def process_bitcoin
  raise 'invalid BTC wallet address' if !BTC.check_address(self.wallet_address)
  BTC.process(self)
end

Why?

Sometimes complex condition checking cannot be avoided. Or the refactoring cost in terms of developer time and code complexity may not be worth pursuing. You might also be working with one of those kinds of engineers that never writes if-else if they can help it.

In this case we can still address the complexity directly by splitting the conditional "checking" part from the actual "processing" so that the reader can do all the conditional tree walking to the finish and "unloads" them from their minds before they start looking at the gist of the actual processing.

Think of this like being a detective. You have to interview several different suspects and find the true culprit. However, there's an extra problem: the road to each of the suspect's houses are very snaky and full of potholes. Imagine you have a clone of yourself yourself, one of you does the driving while the other think about the case. This way, it's a lot more likely to figure out the case.

This accomplishes two more things additional to the first two:

The "switching" of methods are now clear and obvious. The method do not immediately process anything but simply branch to the right processing function.
We minimized the distractions of branching when we look at individual processing methods (.process_credit_card don't talk about bitcoins, .process_bitcoin don't talk about credit cards.) so that each method's processing code are streamlined and more obvious.

Now if another developer is tasked with fixing some issue with credit card processing he can quickly zero-in onto the actual processing code and see everything related to it in one place and can quickly tune-out everything else.

Comparing Boolean Expression to True

Chakrit Wichian — Wed, 17 Mar 2021 17:47:19 +0000

This has to be the oldest trick in the book in the sense that only really early beginner make these mistakes.

Instead of

class User
  attr_reader :username
  attr_reader :email

  def is_valid?
    valid = !self.username.blank? && !self.password.blank?
    valid == true
  end
end

Do this

class User
  attr_reader :username
  attr_reader :email

  def is_valid?
    !self.username.blank? && !self.password.blank?
  end
end

Why?

Boolean expressions eventually resolve to either true or false. Comparing them again to true wastes computation and adds extra cognitive load without actually adding to the readability or explicitlness.

Why Not?

Sometimes you don't always have a binary true or false values. For example, you can have undefined, null or nil values in other languages. In which case, comparing them to true do have a use because you want to avoid the other two (or three) possibility of the value not existing, or the value being false at the same time.

let result = render(template);                  // default options `{}`
result = render(template, { escape: true });    // explicit options

function render(content, options = {}) {
  if (options['escape'] === true) {
    content = htmlEscape(content)
  }

  // ...
}

It may, however, confuses the reader because the absence of value is implicit in this context. Calling out implicitness usually improves readability but reduce succintness and adds conginitive load. So depending on your situation, shorter may be better or explicit may be better.

One way to make this explicit is to split apart the two concerns in the code:

Checking for absence of value
Checking for the value itself

Like so:

function render(content, options = {}) {
  if (typeof options['escape'] !== 'undefined' && options['escape']) {
    content = htmlEscape(content)
  }

  // ...
}

This code calls out to the reader to be on the lookout for the absence of values in the options hash. That not all options maybe passed into the function.

Alternatively, we can eliminate 1) entirely by supplying defaults:

function render(content, options = {}) {
  if (!options.hasOwnProperty('escape')) {
    options['escape'] = defaults['escape']
  }

  // now we are sure the 'escape` option will always be specified
  // our check is now straightforward
  if (options['escape']) {
    content = htmlEscape(content)
  }

  // ...
}

An experienced coder will also notice that the pattern of "applying defaults" can be made more generic and applied uniformly throughout the codebase. This is exactly the usecase of lodash's _.defaults() method which we can use to make the code more succinct:

function render(content, options = {}) {
  _.defaults(options, defaults); // eliminate any "absence of value" cases

  if (options['escape']) {
    content = htmlEscape(content)
  }

  // ...
}

We can avoid Lodash entirely and use null-coalescing operator ?? if your language supports them:

function render(content, options = {}) {
  if (options['escape'] ?? false) {
    content = htmlEscape(content)
  }

  // ...
}

[WIP] Write Better Code

Chakrit Wichian — Wed, 17 Mar 2021 17:46:37 +0000

This series is meant to be a collection of tips, tricks and techniques for writing a more readable and maintainable code. The content will focus exclusively on the style and other subjective elements of code writing. There are already many other content on the web that talk about the semantics and how a piece of code or an algorithm "works". We focus, here, instead on how the code "reads".

That being said, this does not mean we will forego the concern of making sure the code work entirely. We believe, rather, that correctly working code are a result of not only it having correct semantics, but also because the programmer writing/maintaining it can reason about it easily because the code was written with such high readability standards.

In other words, we believe making the code more readable makes it more correct as well.

The content are purely derived from my own personal experience writing, reading and debugging unbelievable number of lines of code over 20+ years. Contributions are, of course, welcome and if this proves to be useful to many people, I'd be happy to open source and license it.

Some of the content found here may feels familiar to readers of coding style books, but, again, I'd like to emphasize that this is distilled from my personal experience only and not summarized from any book. It also have no set plans or publishing schedule, I'll add to it as I have time and feel like I have something useful to contribute. Other times, it may stay static for months or years.

I do believe, however, that there is an ultimate answer to all code styling issues. I believe that after a certain point in the career of programming and software development, most of us eventually come to the same or similar realization/conclusion. So it should be of no coincidence that some concepts found here may have already been explained in some book or some blog post somewhere on the interwebs. In which case , I'll add links and references to the relevant pages.

อยากได้เว็บไซต์ต้องทำไง

Chakrit Wichian — Wed, 06 Nov 2019 06:27:38 +0000

เขียนทิ้งไว้เป็น How-To แบบไวๆ เพราะรู้สึกชอบมีคนมาถาม และคำตอบที่เป็น Default ส่วนมากแม่งโคตรไม่เมกเซ้นส์ หรือว่าเป็นแบบคนจ้างสบาย ที่คนได้เว็บไปปวดหัว

อย่างแรกที่สุดก่อนจะไปถึงว่าจ้างใคร เท่าไหร่ ใช้โปรแกรมไหน ตอบคำถามให้ได้ก่อนว่า อยากให้เว็บไซต์ทำอะไรให้เรา ตัวอย่างเช่น:

อยากให้ร้านดู Professional มากขึ้น
อยากได้ Email แบบ @ชื่อร้าน.com
อยากได้ช่องทางการขาย Online
อยากมีที่ลงข้อมูลให้ลูกค้าอ่าน หรือติดต่อกลับ หรือ Google เจอ
อยากได้ระบบช่วยสนับสนุนการทำงานในร้าน

ที่ต้องถามเพราะว่า Solution ของแต่ละข้อนั้นมันไม่เหมือนกันเลย แต่ถ้าไม่ตอบคำถามนี้ก่อนแล้วตรงดิ่งไปหา　Freelance สิ่งที่เขาจะทำก็คือเขาก็จะให้ Solution ที่เขาถนัดมาแบบที่เขาเคยทำ แต่มันไม่ใช่สิ่งที่ดีสุดสำหรับร้านคุณแน่นอน หรือไม่ใช่สิ่งที่ถูกที่สุดด้วย แล้วเอาจริงๆ มันก็ไม่ใช่หน้าที่เขาที่จะต้องมาแนะนำว่าอะไรดีที่สุด เพราะส่วนมาก สายรับจ้างแบบนี้ เขาก็แค่รับ Requirement คุณมา ทำให้จบ แล้วจบกัน

การหา Freelance มาทำเว็บให้ บอกเลยว่าเป็นคำตอบที่แย่ที่สุดแทบจะทุกครั้ง เหตุผลมีหลายข้อ:

Software ทุกตัวต้องการ Update ตลอดเวลา

Software ทุกตัวมีช่องโหว่ทางด้านความปลอดภัยเสมอ และโดยปกติแล้วคนทำ Software เขาจะมีการอุดช่องโหว่พวกนี้เรื่อยๆ เป็นระยะ และเขาก็จะปล่อย Update มาเรื่อยๆ ทุกเดือน หรือบางตัวอาจจะเป็นทุกอาทิตย์เลยด้วยซ้ำ โดยเฉพาะอย่างยิ่งถ้าคุณใช้ Software ที่คนอื่นเขาให้กันดาดดื่นเช่น Wordpress นี่ตัวดีเลย เพราะใช้กันเยอะมากทั่วโลก

ลองนึกดูว่าถ้าคุณเป็น Hacker แล้วคุณจะมานั่งเจาะเว็บไซต์ทีละเว็บไหม ถ้าคุณมีความรู้ช่องโหว่ของ Wordpress? ไม่เลย คุณก็ใช้วิธียิ่งกวาดไปเลยไง ถ้าคุณไปจ้าง Freelance ทำเว็บให้ แล้วเขาทำ Wordpress มาให้คุณต้องดูให้ดีๆ ว่าเขาตกลง Update ให้คุณไปตลอดการใช้งานไหม ถ้าคำตอบคือไม่ คุณเตรียมโดน Hack ได้เลย

แล้วอย่าบอกว่าร้านคุณ "ไม่มีข้อมูลสำคัญให้ Hacker มาเจาะ" เพราะแค่เขายึด Domain ของคุณได้เขาก็เอาไปทำอะไรได้อีกร้อยแปดพันเก้าเลยครับ บางทีโดยที่คุณไม่รู้ตัวเลยด้วยซ้ำ ยกตัวอย่างง่ายๆ ว่าถ้าคุณเป็นร้านขายเสื้อผ้า แล้ววันนึงลูกค้าคุณได้รับ E-Mail ขายยาปลุกเซ็กส์ที่จั่วหัวเป็นชื่อร้านคุณ คุณคิดว่าเขาจะกลับมาซื้อร้านของคุณอีกไหม? รู้ตัวอีกทีธุรกิจ Online ก็พังแล้ว โดน Google แบนอีก ทั้งๆ ที่หน้าเว็บเปิดเข้าไปดูก็ไม่ได้เป็นอะไรเลย ทุกอย่างปกติเหมือนเดิม (เขาไม่อยากให้เรารู้ตัวไง เขาแค่อยากขโมย E-Mail มายิง Spam)

Software ชิ้นแรกไม่ใช่ Software ชิ้นสุดท้าย

ถ้าคุณเคยได้ทำงานกับคน IT มาบ้าง จะต้องได้ยินคำว่า Agile ไม่มากก็น้อย ตอนนี้มันมีความหมายร้อยแปดพันเก้า แล้วแต่ว่าไปเรียนมาจากสำนักไหน แต่ข้อสำคัญที่คุณควรจะรู้ไว้เลยก็คือว่า สิ่งที่คุณคิดว่าคุณต้องการสำหรับร้านคุณในวันนี้ มันไม่ใช่สิ่งที่จำเป็นจริงๆ สำหรับคุณไปตลอดแน่นอน ปีหน้า เดือนหน้า หรือแม้แต่แค่อาทิิตย์หน้า หรือพรุ่งนี้คุณอาจจะตื่นมาแล้วคิดได้ว่าจริงๆ คุณอยากได้ Function การทำงานอื่น ไม่ใช่สิ่งที่ทำไปแล้วด้วยซ้ำ

ข้อสำคัญก็คือ Requirement ทางธุรกิจมันไม่เคยนิ่งอยู่แล้วครับ ถ้าคุณจ้าง Freelance มาทำให้แล้วคุณส่ง Requirement ไปหนึ่งชุด ถ้าคุณไม่ทบทวนให้ดี คิดให้แน่ Freelance เขาไม่มานั่งแคร์นะครับ ว่าสิ่งที่คุณระบุไปมันจะให้ได้จริงๆ เขาก็แค่ทำให้ดีที่สุดตามที่เขาเข้าใจ แล้วจ่ายเงินเมื่อไหร่ก็จบงาน ถ้าเกิดคุณนึกอยากจะเปลี่ยนอะไรขึ้นมาอีก ง่ายๆ ก็คือเสียเงินเพิ่มไปเรื่อยๆ ครับ

ทุกจุดนึงธุรกิจของคุณจะแข็งเป็ก ปรับเปลี่ยนอะไรยากมาก เพราะว่าจะเปลี่ยนทีนึงต้องเสียเงิน เสียเวลา เสียอารมณ์ นั่งคุย นั่งประชุมกันหลายรอบ พวกนี้เป็นต้นทุนทั้งนั้น

ถามว่า Freelance ดีๆ ที่คิดทุกอย่างให้ ดูแลให้ตลอดทางมีไหม มีครับ แต่คุณมีกำลังจ้างเขารึเปล่า คุณพร้อมจะจ่ายเงินหลักแสนเป็นรายเดือนไหม?

คุณไม่ใช่คนแรกที่อยากได้เว็บ

คิดว่า ณ จุดนี้ทุกคนที่สามารถเปิดมาอ่านบล็อกนี้ได้ น่าจะใช้ Facebook, Twitter เป็นกันหมดแล้ว ลองคิดดูว่าถ้าธุรกิจคุณอยากได้หน้าร้าน หรืออยากได้อีเมล์ ธุรกิจอื่นๆ มันยากมากที่จะมองว่าความต้องการน้ีของธุรกิจของคุณมันเป็นเรื่อง Unique ที่ไม่มีใครเคยทำมาก่อน

สิ่งที่จะบอกก็คือเดี๋ยวนี้มันมี Platform มากมายหลายอย่างให้เลือกใช้อยู่แล้ว แบบที่คลิกๆ แปปเดียวก็ใช้ได้เพราะฉะนั้นพวกนี้คือสิ่งที่คุณควรจะไปตามหาก่อนอย่างแรก ก่อนที่จะคิดว่าต้องจ้างใครมาทำเว็บให้ แถมการใช้งาน Platform พวกนี้มันมีข้อดีที่เน้นหนักมากๆ อยู่สามอย่างคือ

มันถูกกว่าจ้าง Freelance เพราะว่าพวกนี้เขาทำ Software ทีเดียว บริการลูกค้าได้หลายคน ลองคิดดูว่าถ้าราคาจ้าง Freelance ของคุณคือ 15,000 บาทบวกกับความปวดหัวทั้งหลาย เงินก้อนนี้ถ้าเอาไปซื้อ Online Service หนึ่งตัว สมมุติว่าราคา $9.99 ต่อเดือน ก็ตีซะเดือนละ 400 คุณใช้งาน 37.5 เดือนหรือเทียบเป็นปีก็ 3 ปีเศษๆ เลยนะ!

มันมี Function เพียบพร้อมมาให้แล้ว ถ้าคุณไปจ้าง Freelance ทำ คุณก็ต้องไปนั่งไล่รายละเอียดของธุรกิจคุณให้ฟังทีละอย่าง ทำความเข้าใจให้ถูกต้องกัน กว่าจะรู้เรื่อง เริ่มทำกันได้ ก็เป็นเดือนแล้ว แถมนี่คือ Software ที่ทำขึ้นใหม่ มันมีข้อดีข้อเสียยังไง ก็ไม่มีใครรู้ ถ้าคุณไปใช้ Platform ที่คนอื่นเขาทำมาแล้ว คุณไม่ต้องมาเสียเวลาทำอะไรตรงนี้เลย เพราะเขาคิดมาให้หมดแล้ว มีลูกค้าคนอื่นของเขาที่เขาไปเรียนรู้มาแล้วว่าต้องมีอะไรบ้าง ต้องทำอะไรบ้าง เขาทำมาให้แล้ว คุณไม่ต้องไปคิดเองเลย แถมวันนึงถ้าเกิดคุณมีความต้องการใช้อะไรใหม่ๆ มันอาจจะมีคนทำไว้ให้แล้วตั้งแต่แรกด้วยซ้ำ คุณไม่ต้องไปแก้อะไรเลย แค่เข้าเว็บไปเปิดใช้ก็ใช้ได้แล้ว

ผู้ให้บริการเขา Update ทุกอย่างให้คุณโดยอัตโนมัติ คือเมื่อคุณใช้ Platform ร่วมกับคนอื่น อย่างเช่น Facebook อย่างนี้ เวลามีปัญหา มี Bug หรือมีช่องโหว่ด้านความปลอดภัย เขามี Incentive ในการเข้าไปแก้ให้คุณอยู่แล้ว เพราะมันกระทบลูกค้าเขาทุกคนพร้อมกัน คุณไม่ต้องรอให้ปัญหามันเกิด ไม่ต้องรอไปแจ้งให้ใครมาซ่อมให้

เพราะฉะนั้นก่อนจะไปหาคนทำเว็บให้ ลองหา Service ออนไลน์ดูก่อนมันดีกว่ามากๆ

Common Services

อันนี้เขียนทิ้งไว้เป็น List บริการออนไลน์ส่วนน้อยที่เราชอบเป็นการส่วนตัว เผื่อใครอยากกดเข้าไปใช้ ไปสมัครลองทำกันเอง

จดโดเมน

ถ้าอยากมี Web Presence หรือมี .com .net .co.th เป็นของตัวเอง

https://domains.google/
https://www.namecheap.com/
https://www.thnic.co.th/ - สำหรับโดนเมนที่ลงท้ายด้วย .th

ถ้าต้องจัดการ DNS (เช่นติดตั้ง E-Mail บนโดเมนของตัวเอง หรือมี Subdomain หลายๆ อย่าง หรือแค่อยากได้ WAF)

อยากได้อีเมล์ @ชื่อร้าน

ต้องจดโดเมนชื่อร้านก่อนนะ แล้วค่อยมา Setup ตรงนี้

https://gsuite.google.com/ - ตัวมาตรฐาน หน้าตาเหมือน GMail แต่เป็น Domain เราเอง
https://www.zoho.com/ - อันนี้เป็นมวยรองแต่ใช้งานได้เหมือนกัน

ทำการตลาดผ่าน E-Mail (ส่งข่าว แจ้งโปรฯ ฯลฯ)

แชร์ E-Mail ตอบลูกค้าหลายๆ คนพร้อมกัน

ถ้ามี Volume จำนวนปริมาณ E-Mail เยอะมาก แล้วพนักงานตอบกันไม่ทันหรือมีปัญหาแย่งกันตอบ ใครตอบอันไหน ลองใช้พวกนี้ดู

อยากมีหน้าเว็บ หรือร้าน Online

https://wordpress.com/ - ถ้าต้องใช้ Wordpress จริงๆ มาใช้ของต้นน้ำจากเจ้าของโดยตรงที่ตรงนี้ ให้เขา Host ให้ อย่าซ่า Host เอง!
https://www.shopify.com/ - เปิดร้านขายของ แพงหน่อยแต่ฟังก์ชั่นครบ ถ้าอยากได้ถูกไปใช้ WooCommerce บน Wordpress
https://www.wix.com/
https://www.squarespace.com/

แชร์เอกสาร หรือทำ Workflow

https://products.office.com/th-th/business/small-business-solutions - ถ้าเน้นใช้ Office หนักๆ ต้องการแชร์ของกันทุกอาทิตย์ ไปลองกด Office 365 ดู ชีวิตจะสะดวกขึ้นเยอะ
https://docs.google.com/ - ตัวนี้แถมมากับ G-Suite เวลาติดอีเมล์ ถ้าไม่ได้ติดว่าต้องเป็น Microsoft Office แนะนำให้ใช้ตัวนี้ ไม่ต้องเสียตังค์เพิ่ม ออนไลน์ แชร์ง่าย โดยเฉพาะถ้าใช้ Android อยู่แล้วด้วย
https://www.dropbox.com/ - สำหรับแชร์ไฟล์ทั่วไป หรือไฟล์ขนาดใหญ่ ที่ส่งผ่านเมล์ยาก
https://airtable.com/ - สำหรับสร้าง Workflow ตัวนี้ใช้ยากนิดนึง เหมือน Access สมัยก่อน แต่สมัครทีเดียวดัดแปลงได้ร้อยแปดพันเก้า

มีอีกแต่คิดว่าเท่านี้คง Cover เกิน 80% ของที่คนส่วนใหญ่ต้องการละ ถ้ามีอะไร E-Mail มาถามได้ service@chakrit.net

Multiple Identity Gitconfig (with GPG signing)

Chakrit Wichian — Tue, 29 Oct 2019 16:12:40 +0000

Have you ever had these problems like I did?

You work with multiple groups or companies, or you want to separate your work commits from your personal commits.
You want to GPG sign all your commits.
You do not put your personal GPG keys on your work machine, and you do not put your work GPG keys on your personal machine.
You use a different GPG identity (and perhaps, email) for different repository.
You synchronize your dotfiles regularly. It contains your GPG configuration as well as your global .gitconfig and use the same dotfiles repository on both your work machine and your personal machine.

If you did you'll find out that you now have a conflict in your .config/git/config file, namely in the [user] section.

I have mine, looking something like this:

[user]
  name       = Chakrit Wichian
  email      = service@chakrit.example.net
  signingkey = E888C1BC6A4DB2F4

So this tells git, for all my personal projects, to use my personal email and personal GPG key to sign it.

This all works nice and well but then, how do we setup our work accounts?

Previously I have used GNU Stow with multiple git folder in my dotfiles repository and only stow the one I needed into place.

# on personal machine
cd dotfiles && stow git-personal

# on work machine
cd dotfiles && stow git-work

Obviously, though, this approach has an annoying flaw: I cannot synchronize changes easily across all git installations I use.

That got me thinking. What is the BEST approach to this problem? Usually other configuration system have a way to include files so that you can split them into bits and keep most of the shared configuration items the same in the main file and include the parts that are different from other files.

I could modify my workflow so that I have a main configuration that is shared for all installations and have another supplemental configs just for the specific machine I happen to be on.

# shared configuration
cd dotfiles && stow git-base && cd ~
tree

.
└── .config
    ├── git
    │   ├── config # ← contains an include directive.
    │   └── ignore
    └── hub

2 directories, 3 files

# selecting the right "extra" to install
cd dotfiles && stow git-company-x && cd ~
tree

.
└── .config
    ├── git
    │   ├── config
    │   ├── extras # ← contains extras, for company X
    │   └── ignore
    └── hub

2 directories, 4 files

So after realizing this, I began to search for git configuration documentation, seeing if this functionality is available.

To my surprise, the git manual on includes has an EVEN BETTER solution lying in wait for me with the includeIf directive.

Conditional Includes

Git supports a neat way of specifying an includeIf condition by selecting based on the location of the .git dir. And better yet, it also supports ** directory globbing.

This means that you can structure your workspace such that all of Company X's work are under a dir named company-x and then using a condition matching **/company-x/**/.git to match all git checkouts under that dir.

First, if you havn't already, you need to reorganize your repos based on where you work (or how you want to apply gitconfigs):

# example directory tree under your `git/` or something.
tree

.
├── company-x
│   ├── hello-world
│   └── awesome-project
└── personal
    ├── hello-world
    └── awesome-learning

Second, create multiple git configuration files for each different situation.

# config.personal
[user]
  name = Chakrit Wichian
  email = service@chakrit.example.net
  signingkey = E888C1BC6A4DB2F4

# config.company-x
[user]
  name = Chakrit Wichian
  email = chakrit@company-x.example.com
  signingkey = 3CDC219617574C11

Third, in your main git configuration file, adds as many includeIf directive as needed:

# default case
[include]
  path = config.personal

# when working with company-x
[includeIf "gitdir:**/company-x/**/.git"]
  path = config.company-x

Lastly, save all files and test them out!

cd chakrit/secret-project-x
git config user.email
service@chakrit.example.net # ← outputs personal email!

cd ../../company-x/awesome-product-y
git config user.email
chakrit@company-x.example.com # ← outputs work email!

Some other uses that I think is cool follows:

Automatically switching `hub` context.

If the companies you work for uses GHE. You could point the hub CLI to different domains base on where the repo is placed on your system.

# config.company-x
[hub]
  host = git.company-x.example.com

# config.company-y
[hub]
  host = git.company-y.example.com

Different signing settings base on branch.

Aside from the gitdir: matching condition, you can also use onbranch: to setup branch-specific configs!

If you have specific branch system setup, for example master for production commits, you could set it up so that GPG signing is only done there and only require commits on that branch to have proper verification.

# config
[commit]
  gpgsign = false
[includeIf "onbranch:master"]
  path = config.master

# config.master
[commit]
  gpgsign = true

Thanks for reading! Ping me on Twitter and say hi :)

DEV Community: Chakrit Wichian

If/Else Pyramids

Example

Instead of

Do this

Why?

Why Not?

Split Condition

Instead of

Do this

Why?

Comparing Boolean Expression to True

Instead of

Do this

Why?

Why Not?

[WIP] Write Better Code

อยากได้เว็บไซต์ต้องทำไง

Software ทุกตัวต้องการ Update ตลอดเวลา

Software ชิ้นแรกไม่ใช่ Software ชิ้นสุดท้าย

คุณไม่ใช่คนแรกที่อยากได้เว็บ

Common Services

จดโดเมน

อยากได้อีเมล์ @ชื่อร้าน

ทำการตลาดผ่าน E-Mail (ส่งข่าว แจ้งโปรฯ​ ฯลฯ)

แชร์ E-Mail ตอบลูกค้าหลายๆ คนพร้อมกัน

อยากมีหน้าเว็บ หรือร้าน Online

แชร์เอกสาร หรือทำ Workflow

Multiple Identity Gitconfig (with GPG signing)

Conditional Includes

Automatically switching hub context.

Different signing settings base on branch.

ทำการตลาดผ่าน E-Mail (ส่งข่าว แจ้งโปรฯ ฯลฯ)

Automatically switching `hub` context.