#codingstyle

New logicLAB Policy for Perl::Critic Policy: ModuleBlacklist

From the MOTIVATION section in the POD of this new policy:

I once read an article which compared programming languages to natural languages. Programming languages in themselves are not large as such, but if you also regard the APIs, data structures and components a computer programmer use on a daily basis, the amount is enormous.

Where I work We try to keep a more simple code base, the complexity…

วันก่อน พึ่งได้อ่าน เรื่อง Bug ที่เกิดขึ้นใน IOS (ข่าวตั้งแต่ 2014-02)

http://www.wired.com/2014/02/gotofail/

เลยนึกถึง Coding Guideline ข้อหนึ่งที่ผมเคยเขียนให้ทีม โดยบังคับไว้ว่า เมื่อใช้คำสั่ง if จะต้องใส่ braces เสมอ

เป็นข้อบังคับง่ายๆ ที่ป้องกันไม่ให้เกิด bug ในลักษณะนี้ได้ดีพอสมควร

ในช่วงที่ผมต้องหา bug หรือตรวจ code (ซึ่งไม่ได้ตรวจระเอียดหรอก) bug แบบนี้เป็น bug ที่เจอได้บ่อย โดยเฉพาะ code ที่ต้องถูกแก้ไขบ่อยๆด่วนๆ

bug แบบนี้ เป็น bug ที่ tools หลายๆตัวยังตรวจไม่เจอ

หรือตรวจเจอบางแต่ไม่ชัดเจน

แต่ทั้งนี้ก็ยังมี Coding Style หลายๆ Project ก็ยังบังคับให้ ตัด Braces ออกอยู่ เช่น Linux Kernel

ผมก็ไม่ทราบเหตุผลจริงๆ เหมือนกัน ว่าตัดออกแบบดีกว่าจริงๆหรือ .. แต่สำหรับผม การมี braces เสมอ เมื่อเราต้องเปลี่ยน จากหนึ่งคำสั่งไปเป็นหลายคำสั่ง มันทำให้สามารถมองการเปลี่ยนแปลง (ผ่าน diff tools) ได้ง่าย ไม่ต้องไปตรวจการเปลี่ยนแปลงที่ไม่มีความสำคัญ

While pushing changes to Jenkins for review I noticed that I was indenting ruby code too much.. 4 spaces instead of 2 for a tab. This puzzled me as I had a .vimrc which seemed to be correct:

autocmd FileType ruby setlocal shiftwidth=2 tabstop=2 softtabstop=2

Examining the file with the vim command

:set list

showed that there were

^I

characters inserted for every place where I had inserted a tab. Simply trying to reformat using

gg=G

changed nothing. I later realized that I need to expand the tabstops to spaces

autocmd FileType ruby setlocal shiftwidth=2 tabstop=2 softtabstop=2 expandtab

Then within vim

:retab