|
|
|
|
| mplayer的代码写得那么不规范，居然那么多人用 |
  mplayer的代码写得那么不规范，居然那么多人用 - h_falls [ 2005-02-23 18:29 | 908 byte(s)]
Re: mplayer的代码写得那么不规范，居然那么多人用 - baifCc [ 2005-02-24 14:19 | 52 byte(s)]
Re: mplayer的代码写得那么不规范，居然那么多人用 - 徐大侠 [ 2005-02-24 12:39 | 345 byte(s)]
Re: mplayer的代码写得那么不规范，居然那么多人用 - h_falls [ 2005-02-24 13:31 | 247 byte(s)]
你恐怕不经常看片 - 徐大侠 [ 2005-02-24 15:46 | 108 byte(s)]
Re: 你恐怕不经常看片 - shuyong [ 2005-02-24 22:48 | 139 byte(s)]
Re: 你恐怕不经常看片 - h_falls [ 2005-02-24 16:33 | 43 byte(s)]
Re: mplayer的代码写得那么不规范，居然那么多人用 - baifCc [ 2005-02-24 14:23 | 92 byte(s)]
Re: mplayer的代码写得那么不规范，居然那么多人用 - Viperii [ 2005-02-23 20:09 | 141 byte(s)]
Re: mplayer的代码写得那么不规范，居然那么多人用 - h_falls [ 2005-02-23 20:33 | 167 byte(s)]
Re: mplayer的代码写得那么不规范，居然那么多人用 - tclwp [ 2005-02-23 20:16 | 85 byte(s)]
Re: mplayer的代码写得那么不规范，居然那么多人用 - zhangyeming [ 2005-02-25 10:48 | 174 byte(s)]
Re: mplayer的代码写得那么不规范，居然那么多人用 - ACp [ 2005-02-25 16:50 | 42 byte(s)]
Re: mplayer的代码写得那么不规范，居然那么多人用 - teawater [ 2005-02-23 20:41 | 75 byte(s)]
Re: mplayer的代码写得那么不规范，居然那么多人用 - tclwp [ 2005-02-23 22:05 | 30 byte(s)]
Re: mplayer的代码写得那么不规范，居然那么多人用 - h_falls [ 2005-02-23 22:52 | 145 byte(s)]
Re: mplayer的代码写得那么不规范，居然那么多人用 - lonelyflyer [ 2005-02-24 10:54 | 102 byte(s)]
Re: mplayer的代码写得那么不规范，居然那么多人用 - teawater [ 2005-02-23 20:04 | 38 byte(s)]
Re: mplayer的代码写得那么不规范，居然那么多人用 - shuyong [ 2005-02-23 19:51 | 104 byte(s)]
|
|
|
|
[Original]
[Print]
[Top]
|
mplayer的主页上说它还得了个什么奖
http://www.mplayerhq.hu/homepage/design7/news-es.html
投票结果：
MPlayer 487 votos (49.85%)
xine 304 (31.12%)
Totem 77 (7.88%).
我个人觉得xine的架构比mplayer漂亮多了。
mplayer虽然功能强大，但是看看它的代码，问题一堆：
1。 全局变量的命名太随意了，一点规则都没有，看代码烦
2。 一个goto语句go到近千行开外的地方，而且goto的数量也太多了点，可读性差
3。 一个while 循环有一千行，可读性差
4。 很多地方没有用assert检查函数参数的有效性。
5。 没有用gettext做国际化（我个人觉得gettext是比较好的方案）
6。 如果用Lint检查mplayer代码的话。。。。
为什么编码风格这么乱的一个软件居然还能取得这样的成功，大家可有什么意见？
|
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
|
软件是拿来用的,规范有P用。任何一本经典上都教导世人不要goto,但看看很多大师的code,都是想goto之处无不信手go来,包括Berkeley一些传世代码亦是如此。
|
|
----
Where is the RED pill? I want OUT!
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
用goto没什么，我也常用goto
但是我不会像mplayer那样一个goto就go到十万八千里之外去了，我一般goto的距离最多就百把行。
goto的太远了，看代码难受
|
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
|
还有一个可能是项目启动时写手还是个菜鸟或根本没想到会做到那么大，然后越写越大，又没有几会来个大的重构。
|
|
----
General Assembly resolution 217 A (III)
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
mplayer是当前唯一实用的视频播放器。如果没有它，LINUX在多媒体方面就属于不及格了，所以，虽然是拼拼凑凑的东西，怎么评价它的贡献都不过分。
要支持一大堆乱七八糟的视频格式，程序不可能不乱，即使Windows上完全调用Directshow的Media Player Classic也不容易看懂，何况mplayer没有什么现成的底层框架可以依靠，还不得不支持许多Windows上的DLL格式的codec。
|
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
唯一实用？
我个人觉得xine也不错。 xine的架构看起来比mplayer舒服，是用lib的形式发布的，很容易使用。比如如果你只想获取一个mpeg4文件的长度，用mplayer就不行(因为mplayer只是个播放器)，xine就有专门的API来做这些事。
|
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
|
说得绝对一些了。xine是mplayer的竞争对手，同时也是合作者。在xine的主页谈到了这一点，同时xine也使用mplayer开发的ffmpeg库，这是mplayer的贡献。
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
内核代码和应用程序的代码是没有可比性的
对于内核，代码的效率是第一的
但对一般的程序，特别是开源程序
没有那种详细的设计文档，那代码的可读性就很重要了
|
|
|
----
反对一致，拥护等级;反对菠菜，拥护带壳的蜗牛
|
|
[Original]
[Print]
[Top]
|
|
|
声明: 本页内容为中国Linux论坛的内容镜像，文章的版权以及其他所有的相关权利属于中国Linux论坛和相应文章的作者，如果转载，请注明文章来源及相关版权信息。