zoukankan      html  css  js  c++  java
  • 从Pycharm说起

    说实话.作为一个Coder.每天在各种IDE中切换编写Code.如果一个IDE Look and Feel总是无形中影响你每天Code Farm的心情.那该是多么不爽的事情.特别是针对本人对IDE总是有一种天生“洁癖感”.每当一们语言或技术在无意中吸引我.或是已经在粗糙的本文编辑器初体验.都会在两到三天体验期脱离出来.立马调到真正高效率的生成环境去Coding.高效率就意味当然脱不了IDE的支持.

    但是每次更换新的Coding环境.可能我会花上一到两天或更多的时间去了解这门语言或技术的背景和使用场景 解决现实问题等.因为这直接影响我决定是否继续下去.如果在这一切如期进行后.我一般也会上一天的时间去完善设置即将迎接新的Coding IDE设置. 没看错是一天的时间! 类似这次进入Python过程 实在是忍不住说点什么.

    并非我想吐槽Pycharm.它确实是Code Farm Python的利器.我也是在众多Coder推荐下才尝试的使用它来做开发Python的IDE.在试用第一天我就顶购买正版的license.如果你想问我一般情况一天时间到底花在哪?好吧听我慢慢道来.

    首先说说IDE UI界面就是前面提到Look And Feel.

    在开辟一个新的技术领域.花了很多时间来判断这门技术或语言是否值得去学.在IDE选择我一直保持一种亲身体验的标准.原来也会查找网上一些对某些IDE评测.后来发现各种不靠谱.还是得自己亲身验证. Coder与Coder之间喜好和习惯真的不一.所以如果真的找到适合自己的.还是乖乖自己去体验吧.类似开发PHP时就用了一个下午时间试用目前市面所有主流的IDE.说说这次的Python吧.

    你能在官方Guide文档找到如下一篇文章.Integrated Development Environments Python IDES.

    这篇文章如数列举出当前市面所有支持Python IDE工具.别高兴太早.别忘了后面支持列表.因为我下载Python 3.3最新版.但你可以看到只有很少一些IDE支持了Python 3以上版本.well这样也好大大减少选择的范围.

    说到对Pycharm UI第一印象.首先这种界面布局总是让人感觉不够Clean. Ps:如下是我调整后的

    2013-01-31_180531

    IDE在实际Coding过程只需要简单明确三点.

    A:当前项目解决方案目录组织结构

    B:Code Editor 主界面

    C: Debug调试信息输出Console或Error List或错误列表

    D:版本控制集成.[状态显示和版本提交]

    这四元素基本满足Coding过程的需求.但如果你打开一个IDE突然跳出很多莫名奇怪的小窗口.你还需要了解这些窗口干嘛的. Close掉后如果在需要时我需要跑到那去设置它显示啊? 等等…… 这就像你去了解一个SDK框架中某一个极其微小的功能点时. 你都要加载一大堆或是调用一些你完全不知道做什么或是也不想了解一些实现原理和细节时.这也像本来你只想吃到冰激凌上蓝莓.而对方却给你一个制造冰激凌机器给你感受一样的.

    需要和得到的成本完全不成正比啊.

    IDE作为工具本身就是解决开发效率、资源协作调度、版本控制这些非常实用的需求.但是 我想说的是但是……请你在搞定这些功能后.能够考虑一下那些每天即将用到这个IDE用户的心情的.能否在实用和UI美观上做一个很好折中. 不要太过丑陋 也不要太过简单粗糙而导致难以操作. 这些Detail也会影响使用者的心情啊.对我来说首先UI要足够的Clean. 当然这是建立功能强大基础上. 特别对于一些布局混乱的IDE 早已经我安装load出界面那一刻后一份中已经卸载掉了.

    IDEUI布局有两个极端. 一个是过度的开放.完全拥护定制化. 另外一个纯粹就是鸡肋.开放度低定义一些你完全适应的操作习惯去Coding.类似Pycharm就是前者. Setting界面选项就可见一斑:

    2013-01-31_182618

    密密麻麻的操作选项被横贴在一块……

    前者的代价是在复杂度高.如果你觉得你做一个产品. 需要学习的一门工具.而如果这个工具除了徒增的复杂度和极高学习曲线.生产效率和斧头无意. 那这样设计就有问题. 另外一种.就是让你适应它规定Role.这就像每天有人盯着你用双手叫你画画一般.在好的才华和技艺也会在这种规则当然无存.相对前者我更痛恨是后者. 关键词 Open.

    类似上面选项横排. 满眼的信息 排版显得极为混乱.用户关注度在界面呈现出后就已经失去焦点了. 大多早已Confused掉了.做好IDE布局同时能够有一定开放度.

    Code Theme:

    折腾完页面布局.我一般会立即去下去对应编辑器的Code Theme. 因为大多编辑器默认Code Style都是很丑陋. 高亮和代码颜色都无法匹配都不够合理.如果你常用NEtBeans你也会找到类似的ThemeBuilder定制.

    2013-01-31_185415

    可惜Pycharm没有.只有简单的内置几个简单的Theme. 对于配色的细节还不够满意.FontSize 和BackGround Color 对比度太高.只能草草设置如下:L

    2013-01-31_185532

    不知道各位有没有体验”侵入式“Coding体验. 这里还是采用NetBean做对比吧 这是我NetBeans配置的Python的CodeTheme:

    2013-01-31_190059

    很明显[故意设置Dust]你会看到. Editor编辑器为暗色. 而Solution和Console输出的都是明亮色.这个会照成Coding过程中你的注意力会被这些明亮色干扰.无法真正集中到时常变化Editor. 但是如果我们反过来设置成这样 你会看到:

    2013-01-31_190411

    你会看到.Solution和Console背景色都比Editor要深. 这样一来Editor明亮色就更容易吸引你的注意力.而这块也真是高效Coding过程变化最大的一块.一般情况我解决一些批量容易处理Coding需求是.很容易在这种IDE设置情况有着一种下沉的侵入式的体验. 这样会把你全部 注意力的焦点转移到Editor上来,. 而往往根据个人经验 这个过程效率往往比较高.

    所以你才能感觉Look and Feel用户有多大.其实潜在转移注意的焦点.

    当Code Theme是进入这些更细节的一些东西.代码高亮和文本框格式化也是涉及个人操作和细节.我始终是保持一种一种统一的Code Theme Style.这样即使我在不同IDE切换时也会因为Code Theme不同而导致不适应.

    第三是Call –Tip 和Auto-Complete

    本来最早我体验Python过程是在NetBeans.因为它配置简单.只需要打一个插件包.在NetBeans就有了Python的开发环境.其实我的本机上什么都没装.但是NetBeans在引入这个Python同时却失去Call Tip的功能.这也是我抛弃NetBeans的一个重要原因. 完全无提示:

    2013-01-31_191245

    这让我Coding过程出错几率会大大增加.对于那些庞大的类库和方法名 CAll –Tip 已经是无法或缺的.

    好吧我曾任在购买Pycharm license之前.我基本使用所有免费的IDE. 是不是太偏执了. 没办法 不过还是要来逐一吐槽一下:

    首先使用就是PythonWin Editor 看名字就明白基于Windows. 选着使用主要因为它的Call Tip功能强大.只需要Import一个包. 然后F5一下所有函数和变量都能Call –Tips出来,很强大.但痛苦的是不能用来编写wxPython.

    Eric4也是一个很小众的工具.但是我还是用了. Call-Tips功能极弱.而且恶心的是必须先把导入打包用它的工具API Generator 生成API. 最无语的是只能对包里的类和函数进行Call-Tips提示. 这是个巨大缺陷. so give up

    WingIDE的Auto Complete和Call Tips功能都很强大. 比PythonWin要强很多/.它不仅能够提示代码.还能在右侧的工具里显示Doc.不过期Pro是商用版.我只是采用试用. Free版本恰恰就少了这两个及其重要的功能.

    Kodomo当然不陌生了. ActiveState出的IDE. tip功能一般.关键是免费版本的是不能调试的. 况且关键是原来在开发Php时我对这个工具就没有好感.就是因为支持Python原因继续玩弄一下 果断卸载了.

    剩下就是Vim+Emacs 这个都是神器.不用多说.这个篇幅会放在下篇.当然除了如上这些.还使用一些PyScript一些轻量级的IDe 但是Call –Tips功能都不太满意啊. 都在PythonWin之下.果断不理.

    说道这还好Pycharm对Call Tips和Auto complete功能都很完整.对Debug调试支持也很好.也是我愿意付费一个重要原因.

    第四 快捷键.

    对于一个注重全键盘操作Coder来说.如果编辑器不支持这个. 这也是我果断抛弃的原因之一.

    现在基本所有IDE都支持快捷键.但是如果你具有数量Vim.并不想破换中操作习惯该如何? 好的IDE是继承这些操作快捷键并且可以修改和定制.而大多数IDE基本不会考虑这些.如果需要Visual Studio 和Vim切换.转换新的IDE这就需要一个新的过程. 所以快键键保持和定制直接影响coding效率.

    说了这么多.其实开始一门新技术.找到一个好用IDE真的不简单.特别对于我这种吹毛求疵 有洁癖的用户.那更是得非一般功夫.吐槽这么多.还是希望Support IDe功能能真正做到好用 Clean. 美观.这真的是梦想一件事. 如果你每天觉得用IDE都是一件快事. 想不提高开发效率都难啊.

  • 相关阅读:
    Unix命令大全
    vs2008 与 IE8出现的兼容性问题
    Java 创建文件、文件夹以及临时文件
    如何修改Wamp中mysql默认空密码
    PAT 乙级真题 1003.数素数
    Tags support in htmlText flash as3
    DelphiXE4 FireMonkey 试玩记录,开发IOS应用 还是移植
    10 Great iphone App Review sites to Promote your Apps!
    HTML tags in textfield
    Delphi XE4 IOS 开发, "No eligible applications were found“
  • 原文地址:https://www.cnblogs.com/chenkai/p/2888110.html
Copyright © 2011-2022 走看看