文件製作技巧-Word


文件製作是我們資訊人最「基本」，但也最容易忽略的一塊 

文件的好與壞，給人的觀感是差很多的
就算不懂正式格式的人，用一般的美感判斷，也很容易可以分辨出好的文件與壞的文件


那要怎麼產出一個正式、美觀的文件？
如果沒有經過一些指點，其實很難知道到底錯在哪、哪邊不符合格式 


大學期間從大二開始經過教授的「嚴格訓練」後，也有點小心得了
非常感恩那時候教授願意花很多時間，不厭其煩的指正我們文件的錯誤，畢竟這些東西是「經驗」居多!!

 不過這種技巧不像是體育技能，久沒做了常常就會生疏忘記，只好先記下來方便日後複習了。


以下都是個人經驗，有錯誤再麻煩糾正一下啦~

【格式】

  1. 可以上網查APA格式來參考引用的寫法，記得要用最新版本。
  2. 一定要有目錄、頁碼！
  3. 標號直接從上方工具列的「樣式」>「標題」進行設定，就能直接產出目錄
  4. 記得要「左右對齊」，確定最右邊也是對齊的
  5. 不要再用空白鍵跟Enter鍵來排版了...
    善用「Tab」跟「Ctrl+Enter」
  6. 字體要統一(中文可以用標楷體、英文用Times New Roman)
  7. 中文為：壹、一、(一)、1、(1)
    英文為：Ⅰ、(Ⅰ)、A、(A)、a、(a)
    內文段落間文字敘述之數字，利用阿拉伯數字 (1)；(2)；(3) …表示。
  8. 頁首頁尾的部分可以「分節」，不同節之間可以獨立設定格式。
  9. 段落遺留字串要注意。
    不要讓單一行跑到一頁的最頂端，一個選擇是把多一點內容往下一頁移，另一個選擇是把遺留字串整合到上一頁。
  10. 段落要設定第一行縮排兩個字元

【用字遣詞】
  1. 文章中代表同一個意思的詞，要統一。
    例如：中央大學資管系、中大資管、中央資管...，沒有絕對要選哪一個，統一就好。
  2. 正式文件中，不要出現火星文！


一條一條去檢驗是否都有做到
基本上如果都有符合，文件看起來就有一定水準了


想到有新的內容，會持續更新


留言

張貼留言

這個網誌中的熱門文章

API、Method和Library是什麼東西和關係？

圖片
這三者我一直搞不清楚，有時候API跟Method好像差不多，有時候覺得API概念不就跟Library一樣嗎？ 後來發現這三者差別，需要視它們是對於一個"應用程式"而言是在什麼位置。是應用程式本身，還是不相關的應用程式，還是想要與應用程式互動的外部應用程式。 先來個例子： 今天有一個甲應用程式提供了API ReturnNumber(int a) 而甲應用程式裡面的處理是 int ReturnNumber(int a){ return round(random(a)); }; 接著我們一一解釋它們各是甚麼。 round()、random()：是由內建library提供的兩個method ReturnNumber()：是一個自己寫的Method，但因為我們提供它給外部使用，所以也是個API。 假設乙應用程式用了ReturnNumber()這個API，則只能傳進一個參數a，實際上他不知道這個API裡面寫了什麼，只能透過甲提供的文件說明來知道用途。 這個例子可以看到三者的實例，接著再來進一步說明。 ----------------------------------------------------------------------------------------------- API、Method和Library的關係 【Library】 函式庫，指將一群已經寫好的Method(Function)包成一個Library，當我們import這個Library後就能使用其包含的Method。(此處只是個程式語言的稱法不同，Method指Java、Function指C) 【API( A pplication P rogramming I nterface)】 應用程式介面，指提供給 外部程式 存取或是已經寫好的功能，事實上可以把它當作一群Method的集合，外部程式只能用這些Method。 【Method】 在Java稱為Method，類似C的Function，但不完全相同，這又是另一段故事了。 (在物件導向中的Method是綁定Class，所以要用Method一定要先實體化一個Object。ex. student.gohom
閱讀完整內容

《人月神話》簡易心得

這本真的是很有收穫的書籍，對於在軟體產業工作(尤其是by專案)，看完有著很大的共鳴跟反思。（還沒進產業時曾看過一遍，實際工作後再看一遍又有更深的體會。） 重點是這是三十年前寫的書，而隨著技術與工具的進步，軟體專案發展到現在仍然有書中所說的種種困境與難題，看完會覺得作者真的對軟體專案看得很透徹。 簡短心得就把每一章濃縮成我覺得最重要的「一兩句話」，避免太發散。 但書裡面的內容絕對不只、也無法用一句話精準的概括，只是這樣比較方便記憶而已。
閱讀完整內容

新增欄位，該用alter還是create and drop

最近遇到一個需求是需要DB新增欄位 思考後發現有兩種做法 1. Alter Table ... ADD Column 2. create&drop重新建一個新的table：複製舊的資料表格式，並加入新的欄位，再將舊資料表的資料SELECT INTO至新的資料表，最後重新命名為原本的資料表名稱。 作法1的速度非常快，但是在SQL Server中，ALTER ADD的欄位是無法指定排序的，因此新加入的欄位一定會排在最後，我是認為在觀看上有點不便與醜陋。 由於兩種做法都可行，因此問了資深前輩，trade off的考量點應該要有哪些，得到一些原本沒想到的觀點，順便整理記錄一下。 1. 系統是否已經上線 已經上線的系統，如果採用方法2，風險會比較高，因為轉換資料的過程中會lock住資料，萬一資料量大的時候，需要的時間就很長，萬一有其他使用者需要使用，可能會導致連線逾時。 且轉換的過程中，萬一中途有些資料失敗了，會不知道斷在哪裡，造成資料的不一致；如果採用transcation，則會lock更多資料。 2. 造成的影響最小化 在擴充功能的時候，優先考量的一定是有沒有side effect，如果造成side effect會讓系統品質變得更難維護。而方法1跟2，基本上都不太會影響原本系統邏輯（如果當初寫在系統中的使用語法都有明確指定欄位，沒有使用select * from table的寫法），因此在變動所產生的影響最小化考量，1跟2是都可以採用的。 3. 資源耗用量 MS SQL server有提供的圖形化介面操作，可以移動欄位的順序，看起來非常的方便。但如果我們再進階一點去使用「產生指令碼」的功能，會發現 系統做的事情底層還是select into綁上交易的作法 ，只是沒讓我們看到而已，因此資料量愈大（上千萬筆），採用方法2所耗用的資源就愈多。 最終還是選擇的方法1的做法，因為影響最小，且系統已經上線使用。
閱讀完整內容